<?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="https://arxiv.org/abs/2105.06400"/>
	<rdf:li rdf:resource="https://arxiv.org/abs/1901.02950"/>
	<rdf:li rdf:resource="https://github.com/metosin/testit"/>
	<rdf:li rdf:resource="https://github.com/lambdaisland/kaocha"/>
	<rdf:li rdf:resource="https://github.com/weavejester/eftest"/>
	<rdf:li rdf:resource="https://arxiv.org/abs/1809.04563"/>
	<rdf:li rdf:resource="https://disorderlylabs.github.io/"/>
	<rdf:li rdf:resource="https://www.hillelwayne.com/post/metamorphic-testing/"/>
	<rdf:li rdf:resource="https://www.pointfree.co/blog/posts/23-snapshottesting-1-0-delightful-swift-snapshot-testing"/>
	<rdf:li rdf:resource="https://mathlesstraveled.com/2018/07/30/smt-solutions/"/>
	<rdf:li rdf:resource="https://arxiv.org/abs/1710.03720"/>
	<rdf:li rdf:resource="https://medium.com/@rplevy/cybernetics-versus-informatics-understanding-the-type-wars-99878fe956d6"/>
	<rdf:li rdf:resource="http://arxiv.org/abs/1411.6704"/>
	<rdf:li rdf:resource="http://arxiv.org/abs/1412.4395"/>
	<rdf:li rdf:resource="http://arxiv.org/abs/1501.04692"/>
	<rdf:li rdf:resource="http://arxiv.org/abs/1410.5373"/>
	<rdf:li rdf:resource="http://arxiv.org/abs/1307.6294"/>
	<rdf:li rdf:resource="http://lanl.arxiv.org/abs/1412.5711"/>
	<rdf:li rdf:resource="http://arxiv.org/abs/1312.6055"/>
	<rdf:li rdf:resource="http://arxiv.org/abs/1012.3298"/>
	<rdf:li rdf:resource="http://arxiv.org/abs/1309.5740"/>
	<rdf:li rdf:resource="http://arxiv.org/abs/1304.7914"/>
	<rdf:li rdf:resource="http://arxiv.org/abs/1304.1584"/>
	<rdf:li rdf:resource="http://arxiv.org/abs/1109.5416"/>
	<rdf:li rdf:resource="http://arxiv.org/abs/1303.6020"/>
	<rdf:li rdf:resource="http://arxiv.org/abs/1302.0189"/>
	<rdf:li rdf:resource="http://bradfrostweb.com/demo/ish/"/>
	<rdf:li rdf:resource="http://arxiv.org/abs/1212.1791"/>
	<rdf:li rdf:resource="http://betterspecs.org/"/>
	<rdf:li rdf:resource="http://arxiv.org/abs/1208.3337"/>
	<rdf:li rdf:resource="http://thechangelog.com/post/388235527/aruby-cucumber-from-the-command-line"/>
	<rdf:li rdf:resource="http://arxiv.org/abs/1007.3712"/>
	<rdf:li rdf:resource="http://testobsessed.com/wordpress/wp-content/uploads/2007/02/testheuristicscheatsheetv1.pdf"/>
	<rdf:li rdf:resource="http://open.bekk.no/2010/06/02/automated-functional-testing-of-iphone-apps-with-icuke/"/>
	<rdf:li rdf:resource="http://www.threeriversinstitute.org/blog/?p=494"/>
	<rdf:li rdf:resource="http://gojko.net/2010/04/28/acceptance-tests-are-not-a-by-product-of-development/"/>
	<rdf:li rdf:resource="http://github.com/cavalle/steak"/>
	<rdf:li rdf:resource="http://blog.orfjackal.net/2010/04/direct-and-indirect-effects-of-tdd.html"/>
	<rdf:li rdf:resource="http://cannedcukes.heroku.com/"/>
	<rdf:li rdf:resource="http://eggsonbread.com/2010/03/28/my-rspec-best-practices-and-tips/"/>
	<rdf:li rdf:resource="http://blog.webbynode.com/2009/11/07/reusing-webrat-matchers-for-html-validation-in-cucumber/"/>
	<rdf:li rdf:resource="http://iamneato.com/2009/08/01/rspec-and-sinatra-quick-start"/>
	<rdf:li rdf:resource="http://www.getwindmill.com/"/>
	<rdf:li rdf:resource="http://railscasts.com/episodes/166-metric-fu"/>
	<rdf:li rdf:resource="http://www.pathf.com/blogs/2009/05/rails-testing-frequently-asked-questions-the-non-code-version/"/>
	<rdf:li rdf:resource="http://fakeweb.rubyforge.org/"/>
	<rdf:li rdf:resource="http://xunitpatterns.com/Test%20Stub.html"/>
	<rdf:li rdf:resource="http://github.com/btakita/rr/tree/master"/>
	<rdf:li rdf:resource="http://www.pathf.com/blogs/2009/03/using-cucumber-for-acceptance-testing/"/>
	<rdf:li rdf:resource="http://timothyfitz.wordpress.com/2009/02/08/continuous-deployment/"/>
	<rdf:li rdf:resource="http://startuplessonslearned.blogspot.com/2009/02/continuous-deployment-and-continuous.html"/>
	<rdf:li rdf:resource="http://giantrobots.thoughtbot.com/2009/2/20/mixing-cucumber-with-test-unit"/>
	<rdf:li rdf:resource="http://jania.pe.kr/aw/moin.cgi/JSSpec"/>
	<rdf:li rdf:resource="http://ericholscher.com/tag/testing-series/"/>
	<rdf:li rdf:resource="http://www.voidspace.org.uk/python/mock.html"/>
	<rdf:li rdf:resource="http://broadband.mpi-sws.mpg.de/transparency/bttest.php"/>
	<rdf:li rdf:resource="http://crookedtimber.org/2008/06/07/the-perfect-exam-paper/"/>
	<rdf:li rdf:resource="http://blog.davidchelimsky.net/articles/2008/05/27/rspec-1-1-4"/>
	<rdf:li rdf:resource="http://rubyphunk.com/2008/4/28/ann-rspactor-0-9-10-some-people-call-it-beta"/>
	<rdf:li rdf:resource="http://daveastels.com/index.php?p=5"/>
	<rdf:li rdf:resource="http://peripateticaxiom.blogspot.com/2006/05/complexity-and-test-first-0.html"/>
	<rdf:li rdf:resource="http://www.isri.unlv.edu/ISRI/OCRtk"/>
	<rdf:li rdf:resource="http://rspec.rubyforge.org/"/>
	<rdf:li rdf:resource="http://www.pgdp.net/c/faq/ppv.php#checks"/>
	<rdf:li rdf:resource="http://www.philol.msu.ru/~otipl/new/main/mol/samples-2003-en.php"/>
	<rdf:li rdf:resource="http://blog.objectmentor.com/articles/2007/06/20/creationism-versus-natural-selection"/>
	<rdf:li rdf:resource="http://www.opentick.com/"/>
	<rdf:li rdf:resource="http://vitalbrew.blogspot.com/2006/03/emergent-documentation.html"/>
	<rdf:li rdf:resource="http://nunit.com/nunit/?p=releaseNotes&amp;r=2.4"/>
	<rdf:li rdf:resource="http://blog.daveastels.com/files/BDD_Intro.pdf"/>
      </rdf:Seq>
    </items>
  </channel><item rdf:about="https://arxiv.org/abs/2105.06400">
    <title>[2105.06400] TabLeX: A Benchmark Dataset for Structure and Content Information Extraction from Scientific Tables</title>
    <dc:date>2022-05-01T12:00:29+00:00</dc:date>
    <link>https://arxiv.org/abs/2105.06400</link>
    <dc:creator>Vaguery</dc:creator><description><![CDATA[Information Extraction (IE) from the tables present in scientific articles is challenging due to complicated tabular representations and complex embedded text. This paper presents TabLeX, a large-scale benchmark dataset comprising table images generated from scientific articles. TabLeX consists of two subsets, one for table structure extraction and the other for table content extraction. Each table image is accompanied by its corresponding LATEX source code. To facilitate the development of robust table IE tools, TabLeX contains images in different aspect ratios and in a variety of fonts. Our analysis sheds light on the shortcomings of current state-of-the-art table extraction models and shows that they fail on even simple table images. Towards the end, we experiment with a transformer-based existing baseline to report performance scores. In contrast to the static benchmarks, we plan to augment this dataset with more complex and diverse tables at regular intervals.
]]></description>
<dc:subject>OCR natural-language-processing training-data rather-interesting testing machine-learning to-write-about to-visualize consider:performance-measures</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:Vaguery/b:bfd70a136988/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:OCR"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:natural-language-processing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:training-data"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:rather-interesting"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:machine-learning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:to-write-about"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:to-visualize"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:consider:performance-measures"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://arxiv.org/abs/1901.02950">
    <title>[1901.02950] Spectral Approach to Verifying Non-linear Arithmetic Circuits</title>
    <dc:date>2020-03-20T16:35:16+00:00</dc:date>
    <link>https://arxiv.org/abs/1901.02950</link>
    <dc:creator>Vaguery</dc:creator><description><![CDATA[This paper presents a fast and effective computer algebraic method for analyzing and verifying non-linear integer arithmetic circuits using a novel algebraic spectral model. It introduces a concept of algebraic spectrum, a numerical form of polynomial expression; it uses the distribution of coefficients of the monomials to determine the type of arithmetic function under verification. In contrast to previous works, the proof of functional correctness is achieved by computing an algebraic spectrum combined with a local rewriting of word-level polynomials. The speedup is achieved by propagating coefficients through the circuit using And-Inverter Graph (AIG) datastructure. The effectiveness of the method is demonstrated with experiments including standard and Booth multipliers, and other synthesized non-linear arithmetic circuits up to 1024 bits containing over 12 million gates.
]]></description>
<dc:subject>nonlinear-dynamics electronics engineering-design rather-interesting digital-circuits verification testing simulation to-write-about to-simulate consider:genetic-programming</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:Vaguery/b:86a6958a9054/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:nonlinear-dynamics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:electronics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:engineering-design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:rather-interesting"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:digital-circuits"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:verification"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:simulation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:to-write-about"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:to-simulate"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:consider:genetic-programming"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/metosin/testit">
    <title>metosin/testit: Midje like assertions for Clojure.test</title>
    <dc:date>2019-09-29T10:46:55+00:00</dc:date>
    <link>https://github.com/metosin/testit</link>
    <dc:creator>Vaguery</dc:creator><description><![CDATA[Midje style assertions for clojure.test]]></description>
<dc:subject>Clojure testing to-try library rather-interesting Midje</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:Vaguery/b:0cdf6dde740a/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:Clojure"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:to-try"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:library"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:rather-interesting"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:Midje"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/lambdaisland/kaocha">
    <title>lambdaisland/kaocha: Full featured next gen Clojure test runner</title>
    <dc:date>2019-09-29T10:46:11+00:00</dc:date>
    <link>https://github.com/lambdaisland/kaocha</link>
    <dc:creator>Vaguery</dc:creator><description><![CDATA[Full featured next generation test runner for Clojure.

]]></description>
<dc:subject>Clojure software-development-is-not-programming testing to-try rather-interesting</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:Vaguery/b:739daa10e3c6/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:Clojure"/>
	<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:testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:to-try"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:rather-interesting"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/weavejester/eftest">
    <title>weavejester/eftest: Fast and pretty Clojure test runner</title>
    <dc:date>2019-09-29T10:45:15+00:00</dc:date>
    <link>https://github.com/weavejester/eftest</link>
    <dc:creator>Vaguery</dc:creator><description><![CDATA[Eftest is a fast and pretty Clojure test runner.

]]></description>
<dc:subject>Clojure programming library testing to-try software-development-is-not-programming</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:Vaguery/b:dba344d0ba67/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:Clojure"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:programming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:library"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:to-try"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:software-development-is-not-programming"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://arxiv.org/abs/1809.04563">
    <title>[1809.04563] Finding Higher Order Mutants Using Variational Execution</title>
    <dc:date>2019-07-25T11:00:55+00:00</dc:date>
    <link>https://arxiv.org/abs/1809.04563</link>
    <dc:creator>Vaguery</dc:creator><description><![CDATA[Mutation testing is an effective but time consuming method for gauging the quality of a test suite. It functions by repeatedly making changes, called mutants, to the source code and checking whether the test suite fails (i.e., whether the mutant is killed). Recent work has shown cases in which applying multiple changes, called a higher order mutation, is more difficult to kill than a single change, called a first order mutation. Specifically, a special kind of higher order mutation, called a strongly subsuming higher order mutation (SSHOM), can enable equivalent accuracy in assessing the quality of the test suite with fewer executions of tests. Little is known about these SSHOMs, as they are difficult to find. Our goal in this research is to identify a faster, more reliable method for finding SSHOMs in order to characterize them in the future. We propose an approach based on variational execution to find SSHOMs. Preliminary results indicate that variational execution performs better than the existing genetic algorithm in terms of speed and completeness of results. Out of a set of 33 first order mutations, our variational execution approach finds all 38 SSHOMs in 4.5 seconds, whereas the genetic algorithm only finds 36 of the 38 SSHOMs in 50 seconds.
]]></description>
<dc:subject>software-development testing evolutionary-algorithms rather-interesting complementation to-write-about</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:Vaguery/b:163677071b72/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:software-development"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:evolutionary-algorithms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:rather-interesting"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:complementation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:to-write-about"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://disorderlylabs.github.io/">
    <title>Disorderly Labs</title>
    <dc:date>2019-04-17T11:57:21+00:00</dc:date>
    <link>https://disorderlylabs.github.io/</link>
    <dc:creator>Vaguery</dc:creator><description><![CDATA[Distributed systems are difficult to program and near impossible to debug. Existing tools that focus on single-node computation are poorly-suited to diagnose errors that involve the interaction of many machines over time. The database notion of provenance would appear better suited to answering the sort of cause-and-effect questions that arise during debugging, but existing provenance-based approaches target only a narrow set of debugging scenarios. In this paper, we explore the limits of provenance-based debugging. We propose a simple query language to express common debugging questions as expressions over provenance graphs capturing traces of distributed executions. We show how when programs and their correctness properties are written in a high-level declarative language, we can go a step further than highlighting errors and generate repairs for distributed programs. We validate our prototype debugger, Nemo, on six protocols from our taxonomy of 52 real-world distributed bugs, either generating repair rules or pointing the programmer to root causes.
]]></description>
<dc:subject>computer-science testing distributed-systems heuristics rather-interesting algorithms to-understand</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:Vaguery/b:10ddf6d7716c/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:computer-science"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:distributed-systems"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:heuristics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:rather-interesting"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:algorithms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:to-understand"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.hillelwayne.com/post/metamorphic-testing/">
    <title>Metamorphic Testing • Hillel Wayne</title>
    <dc:date>2019-03-26T12:38:12+00:00</dc:date>
    <link>https://www.hillelwayne.com/post/metamorphic-testing/</link>
    <dc:creator>Vaguery</dc:creator><description><![CDATA[Confession: I read the ACM Magazine. This makes me a dweeb even in programming circles. One of the things I found in it is “Metamorphic Testing”. I’ve never heard of it, and nobody I knew heard about it either. But the academic literature was shockingly impressive: many incredibly successful case studies in wildly different fields. So why haven’t we heard of it before? There’s only one article anywhere targeted at people outside academia. Let’s make it two.

]]></description>
<dc:subject>machine-learning testing stress-testing to-write-about software-development-is-not-programming rather-interesting metamorphic-testing</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:Vaguery/b:e65226a9e6fe/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:machine-learning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:stress-testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:to-write-about"/>
	<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:rather-interesting"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:metamorphic-testing"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.pointfree.co/blog/posts/23-snapshottesting-1-0-delightful-swift-snapshot-testing">
    <title>SnapshotTesting 1.0: Delightful Swift snapshot testing</title>
    <dc:date>2018-12-12T00:17:37+00:00</dc:date>
    <link>https://www.pointfree.co/blog/posts/23-snapshottesting-1-0-delightful-swift-snapshot-testing</link>
    <dc:creator>Vaguery</dc:creator><description><![CDATA[The iOS community has been a large proponent of snapshot testing, mostly thanks to the wonderful iOSSnapshotTestCase library (formerly known as FBSnapshotTestCase). It introduced a new kind of test coverage for iOS applications by allowing us to assert against an image screenshot of a UI component. This is a whole new level of testing that can catch regressions in the pixel data of our UI so that you can make sure that future changes and refactors do not introduce visual regressions into your views.

However, iOSSnapshotTestCase has not evolved much over the years, and its still largely written in Objective-C, which means the API isn’t as generic and composable as it could be in Swift. Also, it only allows snapshotting CALayers and UIViews into a PNG format, but there are many more types we might want to snapshot and many more formats we want to snapshot into.

That’s why today we are excited to officially announce SnapshotTesting 1.0: a modern, composable snapshot testing library built entirely in Swift!

]]></description>
<dc:subject>testing Swift user-experience to-do iOS software-development</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:Vaguery/b:a3facff13b4f/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:Swift"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:user-experience"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:to-do"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:iOS"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:software-development"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://mathlesstraveled.com/2018/07/30/smt-solutions/">
    <title>SMT solutions | The Math Less Traveled</title>
    <dc:date>2018-08-20T12:23:45+00:00</dc:date>
    <link>https://mathlesstraveled.com/2018/07/30/smt-solutions/</link>
    <dc:creator>Vaguery</dc:creator><description><![CDATA[In my last post I described the general approach I used to draw orthogons using an SMT solver, but left some of the details as exercises. In this post I’ll explain the solutions I came up with.

]]></description>
<dc:subject>geometry programming rather-interesting representation testing to-write-about mathematical-recreations nudge-targets consider:looking-to-see</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:Vaguery/b:d8ff96f5c1be/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:geometry"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:programming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:rather-interesting"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:representation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:to-write-about"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:mathematical-recreations"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:nudge-targets"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:consider:looking-to-see"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://arxiv.org/abs/1710.03720">
    <title>[1710.03720] Practical Integer Overflow Prevention</title>
    <dc:date>2018-02-06T00:34:02+00:00</dc:date>
    <link>https://arxiv.org/abs/1710.03720</link>
    <dc:creator>Vaguery</dc:creator><description><![CDATA[Integer overflows in commodity software are a main source for software bugs, which can result in exploitable memory corruption vulnerabilities and may eventually contribute to powerful software based exploits, i.e., code reuse attacks (CRAs). 
In this paper, we present IntGuard , a tool that can repair integer overflows with high-quality source code repairs. Specifically, given the source code of a program, IntGuard first discovers the location of an integer overflow error by using static source code analysis and satisfiability modulo theories (SMT) solving. IntGuard then generates integer multi-precision code repairs based on modular manipulation of SMT constraints as well as an extensible set of customizable code repair patterns. 
We have implemented and evaluated IntGuard with 2052 C programs (approx. 1 Mil. LOC) available in the currently largest open- source test suite for C/C++ programs and with a benchmark containing large and complex programs. The evaluation results show that IntGuard can precisely (i.e., no false positives are accidentally repaired), with low computational and runtime overhead repair programs with very small binary and source code blow-up. In a controlled experiment, we show that IntGuard is more time-effective and achieves a higher repair success rate than manually generated code repairs.
]]></description>
<dc:subject>software-engineering testing security rather-interesting nudge-targets consider:stress-testing</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:Vaguery/b:d2a5d9bfb087/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:software-engineering"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:security"/>
	<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:stress-testing"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://medium.com/@rplevy/cybernetics-versus-informatics-understanding-the-type-wars-99878fe956d6">
    <title>Cybernetics Versus Informatics: Understanding the Type Wars</title>
    <dc:date>2017-12-23T11:07:12+00:00</dc:date>
    <link>https://medium.com/@rplevy/cybernetics-versus-informatics-understanding-the-type-wars-99878fe956d6</link>
    <dc:creator>Vaguery</dc:creator><description><![CDATA[In the “Type Wars” article we referred to above, Bob makes a case that TDD (and presumably generative testing) is what dynamic languages have to offer in place of a type system. While the truth of this is evident to those who have experience with it, what might not be readily evident is that this is one of many examples of the cybernetic tradition in software development. TDD (and BDD, etc) is an outside-in approach that emphasizes the runtime behavior of the system under test. The purpose is to make systems more robust to changing conditions. Tests can be viewed as regulating the behavior of code, keeping functional requirements in place as the code that produces behaviors evolves over time.]]></description>
<dc:subject>testing software-development software-development-is-not-programming philosophy-of-engineering rather-interesting to-write-about</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:Vaguery/b:ea2f8fd9bb8e/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:testing"/>
	<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:philosophy-of-engineering"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:rather-interesting"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:to-write-about"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://arxiv.org/abs/1411.6704">
    <title>[1411.6704] Data Generation for Testing and Grading SQL Queries</title>
    <dc:date>2015-09-20T22:41:05+00:00</dc:date>
    <link>http://arxiv.org/abs/1411.6704</link>
    <dc:creator>Vaguery</dc:creator><description><![CDATA[Correctness of SQL queries is usually tested by executing the queries on one or more datasets. Erroneous queries are often the results of small changes, or mutations of the correct query. A mutation Q' of a query Q is killed by a dataset D if Q(D) ≠ Q'(D). Earlier work on the XData system showed how to generate datasets that kill all mutations in a class of mutations that included join type and comparison operation mutations. 
In this paper, we extend the XData data generation techniques to handle a wider variety of SQL queries and a much larger class of mutations. We have also built a system for grading SQL queries using the datasets generated by XData. We present a study of the effectiveness of the datasets generated by the extended XData approach, using a variety of queries including queries submitted by students as part of a database course. We show that the XData datasets outperform predefined datasets as well as manual grading done earlier by teaching assistants, while also avoiding the drudgery of manual correction. Thus, we believe that our techniques will be of great value to database course instructors and TAs, particularly to those of MOOCs. It will also be valuable to database application developers and testers for testing SQL queries.
]]></description>
<dc:subject>databases testing proof coevolution verification nudge-targets consider:robustness</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:Vaguery/b:07a95ea6761a/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:databases"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:proof"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:coevolution"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:verification"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:nudge-targets"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:consider:robustness"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://arxiv.org/abs/1412.4395">
    <title>[1412.4395] Dafny: Statically Verifying Functional Correctness</title>
    <dc:date>2015-09-20T21:57:09+00:00</dc:date>
    <link>http://arxiv.org/abs/1412.4395</link>
    <dc:creator>Vaguery</dc:creator><description><![CDATA[This report presents the Dafny language and verifier, with a focus on describing the main features of the language, including pre- and postconditions, assertions, loop invariants, termination metrics, quantifiers, predicates and frames. Examples of Dafny code are provided to illustrate the use of each feature, and an overview of how Dafny translates programming code into a mathematical proof of functional verification is presented. The report also includes references to useful resources on Dafny, with mentions of related works in the domain of specification languages.
]]></description>
<dc:subject>programming-language rather-interesting annotations metaprogramming testing representation</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:Vaguery/b:783cba7436fd/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:programming-language"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:rather-interesting"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:annotations"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:metaprogramming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:representation"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://arxiv.org/abs/1501.04692">
    <title>[1501.04692] Reflective Network Tomography Based on Compressed Sensing</title>
    <dc:date>2015-07-05T11:26:22+00:00</dc:date>
    <link>http://arxiv.org/abs/1501.04692</link>
    <dc:creator>Vaguery</dc:creator><description><![CDATA[Network tomography means to estimate internal link states from end-to-end path measurements. In conventional network tomography, to make packets transmissively penetrate a network, a cooperation between transmitter and receiver nodes is required, which are located at different places in the network. In this paper, we propose a reflective network tomography, which can totally avoid such a cooperation, since a single transceiver node transmits packets and receives them after traversing back from the network. Furthermore, we are interested in identification of a limited number of bottleneck links, so we naturally introduce compressed sensing technique into it. Allowing two kinds of paths such as (fully) loopy path and folded path, we propose a computationally-efficient algorithm for constructing reflective paths for a given network. In the performance evaluation by computer simulation, we confirm the effectiveness of the proposed reflective network tomography scheme.
]]></description>
<dc:subject>network-theory networks rather-interesting testing inference algorithms nudge-targets graph-theory</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:Vaguery/b:c3c17bb7e336/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:network-theory"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:networks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:rather-interesting"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:inference"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:algorithms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:nudge-targets"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:graph-theory"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://arxiv.org/abs/1410.5373">
    <title>[1410.5373] Poisson Group Testing: A Probabilistic Model for Boolean Compressed Sensing</title>
    <dc:date>2015-06-27T18:54:30+00:00</dc:date>
    <link>http://arxiv.org/abs/1410.5373</link>
    <dc:creator>Vaguery</dc:creator><description><![CDATA[We introduce a novel probabilistic group testing framework, termed Poisson group testing, in which the number of defectives follows a right-truncated Poisson distribution. The Poisson model has a number of new applications, including dynamic testing with diminishing relative rates of defectives. We consider both nonadaptive and semi-adaptive identification methods. For nonadaptive methods, we derive a lower bound on the number of tests required to identify the defectives with a probability of error that asymptotically converges to zero; in addition, we propose test matrix constructions for which the number of tests closely matches the lower bound. For semi-adaptive methods, we describe a lower bound on the expected number of tests required to identify the defectives with zero error probability. In addition, we propose a stage-wise reconstruction algorithm for which the expected number of tests is only a constant factor away from the lower bound. The methods rely only on an estimate of the average number of defectives, rather than on the individual probabilities of subjects being defective.
]]></description>
<dc:subject>experimental-design testing information-theory statistics models nudge-targets consider:rediscovery rather-interesting</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:Vaguery/b:c5a3aa18439b/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:experimental-design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:information-theory"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:statistics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:models"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:nudge-targets"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:consider:rediscovery"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:rather-interesting"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://arxiv.org/abs/1307.6294">
    <title>[1307.6294] A new graph-based two-sample test for multivariate and object data</title>
    <dc:date>2015-05-28T11:36:46+00:00</dc:date>
    <link>http://arxiv.org/abs/1307.6294</link>
    <dc:creator>Vaguery</dc:creator><description><![CDATA[Two-sample tests for multivariate data and especially for non-Euclidean data are not well explored. This paper presents a novel test statistic based on a similarity graph constructed on the pooled observations from the two samples. It can be applied to multivariate data and non-Euclidean data as long as a dissimilarity measure on the sample space can be defined, which can usually be provided by domain experts. Existing tests based on a similarity graph lack power either for location or for scale alternatives. The new test utilizes a common pattern that was overlooked previously, and works for both types of alternatives. The test exhibits substantial power gains in simulation studies. Its asymptotic permutation null distribution is derived and shown to work well under finite samples, facilitating its application to large data sets. The new test is illustrated on two applications: The assessment of covariate balance in a matched observational study, and the comparison of network data under different conditions.
]]></description>
<dc:subject>statistics comparison testing algorithms dissimilarity</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:Vaguery/b:f7e678abafa5/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:statistics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:comparison"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:algorithms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:dissimilarity"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://lanl.arxiv.org/abs/1412.5711">
    <title>[1412.5711] Simulation leagues: Enabling replicable and robust investigation of complex robotic systems</title>
    <dc:date>2014-12-28T14:04:20+00:00</dc:date>
    <link>http://lanl.arxiv.org/abs/1412.5711</link>
    <dc:creator>Vaguery</dc:creator><description><![CDATA[Physically-realistic simulated environments are powerful platforms for enabling measurable, replicable and statistically-robust investigation of complex robotic systems. Such environments are epitomised by the RoboCup simulation leagues, which have been successfully utilised to conduct massively-parallel experiments in topics including: optimisation of bipedal locomotion, self-localisation from noisy perception data and planning complex multi-agent strategies without direct agent-to-agent communication. Many of these systems are later transferred to physical robots, making the simulation leagues invaluable well-beyond the scope of simulated soccer matches. In this study, we provide an overview of the RoboCup simulation leagues and describe their properties as they pertain to replicable and robust robotics research. To demonstrate their utility directly, we leverage the ability to run parallelised experiments to evaluate different competition formats (e.g. round robin) for the RoboCup 2D simulation league. Our results demonstrate that a previously-proposed hybrid format minimises fluctuations from 'true' (statistically-significant) team performance rankings within the time constraints of the RoboCup world finals. Our experimental analysis would be impossible with physical robots alone, and we encourage other researchers to explore the potential for enriching their experimental pipelines with simulated components, both to minimise experimental costsand enable others to replicate and expand upon their results in a hardware-independent manner.
]]></description>
<dc:subject>simulation testing robotics acceptance-testing standards-setting replicability engineering-design</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:Vaguery/b:0ea0bc87f7fe/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:simulation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:robotics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:acceptance-testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:standards-setting"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:replicability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:engineering-design"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://arxiv.org/abs/1312.6055">
    <title>[1312.6055] Unit Tests for Stochastic Optimization</title>
    <dc:date>2014-03-30T11:55:43+00:00</dc:date>
    <link>http://arxiv.org/abs/1312.6055</link>
    <dc:creator>Vaguery</dc:creator><description><![CDATA[Optimization by stochastic gradient descent is an important component of many large-scale machine learning algorithms. A wide variety of such optimization algorithms have been devised; however, it is unclear whether these algorithms are robust and widely applicable across many different optimization landscapes. In this paper we develop a collection of unit tests for stochastic optimization. Each unit test rapidly evaluates an optimization algorithm on a small-scale, isolated, and well-understood difficulty, rather than in real-world scenarios where many such issues are entangled. Passing these unit tests is not sufficient, but absolutely necessary for any algorithms with claims to generality or robustness. We give initial quantitative and qualitative results on numerous established algorithms. The testing framework is open-source, extensible, and easy to apply to new algorithms.
]]></description>
<dc:subject>testing not-exactly-unit-testing-but-the-thought-counts acceptance-testing machine-learning test-suites performance-measure robustness interesting horse-races stamp-collecting performance-space</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:Vaguery/b:9c8fe9b60447/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:not-exactly-unit-testing-but-the-thought-counts"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:acceptance-testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:machine-learning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:test-suites"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:performance-measure"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:robustness"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:interesting"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:horse-races"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:stamp-collecting"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:performance-space"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://arxiv.org/abs/1012.3298">
    <title>[1012.3298] An Age-Dependent Branching Model for Evolution</title>
    <dc:date>2013-10-13T12:06:55+00:00</dc:date>
    <link>http://arxiv.org/abs/1012.3298</link>
    <dc:creator>Vaguery</dc:creator><description><![CDATA[The balance or symmetry of phylogenetic trees exhibits a systematic deviation from the expectation of a purely random tree growth process as in the Yule model. Here we introduce a one-parametric family of branching models in which branching probabilities decrease with branch ages. We test a measure of imbalance, the dependence of depth on tree size $n$, and find a transition between qualitatively different scaling regimes. Right at the transition point tree depth grows as $(\log n)^2$, which is in good agreement with the trend observed in phylogenetic databases. Depth distributions are also closer to data than the ones from available tree models.
]]></description>
<dc:subject>cladistics branching-processes phylogenetics theoretical-biology testing algorithms</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:Vaguery/b:2c3545256b22/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:cladistics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:branching-processes"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:phylogenetics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:theoretical-biology"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:algorithms"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://arxiv.org/abs/1309.5740">
    <title>[1309.5740] Identifying Graphical Models</title>
    <dc:date>2013-09-24T11:15:27+00:00</dc:date>
    <link>http://arxiv.org/abs/1309.5740</link>
    <dc:creator>Vaguery</dc:creator><description><![CDATA[The ability to identify reliably a positive or negative partial correlation between the expression levels of two genes is influenced by the number $p$ of genes, the number $n$ of analyzed samples, and the statistical properties of the measurements. Classical statistical theory teaches that the product of the root sample size multiplied by the size of the partial correlation is the crucial quantity. But this has to be combined with some adjustment for multiplicity depending on $p$, which makes the classical analysis somewhat arbitrary. We investigate this problem through the lens of the Kullback-Leibler divergence, which is a measure of the average information for detecting an effect. We conclude that commonly sized studies in genetical epidemiology are not able to reliably detect moderately strong links.
]]></description>
<dc:subject>statistics GWAS inference modeling testing should-ask-a-pro-about-this-one</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:Vaguery/b:3c78a77e414b/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:statistics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:GWAS"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:inference"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:modeling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:should-ask-a-pro-about-this-one"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://arxiv.org/abs/1304.7914">
    <title>[1304.7914] A Characterization of Saturated Designs for Factorial Experiments</title>
    <dc:date>2013-05-21T22:49:43+00:00</dc:date>
    <link>http://arxiv.org/abs/1304.7914</link>
    <dc:creator>Vaguery</dc:creator><description><![CDATA[In this paper we study saturated fractions of factorial designs under the perspective of Algebraic Statistics. We define a criterion to check whether a fraction is saturated or not with respect to a given model. The proposed criterion is based purely on combinatorial objects. Our technique is particularly useful when several fractions are needed. We also show how to generate random saturated fractions with given projections, by applying the theory of Markov bases for contingency tables.
]]></description>
<dc:subject>design-of-experiments testing factorial-design combinatorics nudge-targets</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:Vaguery/b:308ed5cfc57f/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:design-of-experiments"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:factorial-design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:combinatorics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:nudge-targets"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://arxiv.org/abs/1304.1584">
    <title>[1304.1584] A Scalable and Nearly Uniform Generator of SAT Witnesses</title>
    <dc:date>2013-04-08T19:35:46+00:00</dc:date>
    <link>http://arxiv.org/abs/1304.1584</link>
    <dc:creator>Vaguery</dc:creator><description><![CDATA[Functional verification constitutes one of the most challenging tasks in the development of modern hardware systems, and simulation-based verification techniques dominate the functional verification landscape. A dominant paradigm in simulation-based verification is directed random testing, where a model of the system is simulated with a set of random test stimuli that are uniformly or near-uniformly distributed over the space of all stimuli satisfying a given set of constraints. Uniform or near-uniform generation of solutions for large constraint sets is therefore a problem of theoretical and practical interest. For Boolean constraints, prior work offered heuristic approaches with no guarantee of performance, and theoretical approaches with proven guarantees, but poor performance in practice. We offer here a new approach with theoretical performance guarantees and demonstrate its practical utility on large constraint sets.]]></description>
<dc:subject>satisfiability verification algorithms nudge-targets computational-complexity testing approximation interesting</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:Vaguery/b:913ba581a4e3/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:satisfiability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:verification"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:algorithms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:nudge-targets"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:computational-complexity"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:approximation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:interesting"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://arxiv.org/abs/1109.5416">
    <title>[1109.5416] Matrix Code</title>
    <dc:date>2013-04-08T19:18:09+00:00</dc:date>
    <link>http://arxiv.org/abs/1109.5416</link>
    <dc:creator>Vaguery</dc:creator><description><![CDATA[Matrix Code gives imperative programming a mathematical semantics and heuristic power comparable in quality to functional and logic programming. A program in Matrix Code is developed incrementally from a specification in pre/post-condition form. The computations of a code matrix are characterized by powers of the matrix when it is interpreted as a transformation in a space of vectors of logical conditions. Correctness of a code matrix is expressed in terms of a fixpoint of the transformation. The abstract machine for Matrix Code is the dual-state machine, which we present as a variant of the classical finite-state machine.]]></description>
<dc:subject>computer-science imperative-programming language testing automata interesting</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:Vaguery/b:02ce0328446d/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:computer-science"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:imperative-programming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:language"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:automata"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:interesting"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://arxiv.org/abs/1303.6020">
    <title>[1303.6020] Multi-Group Testing</title>
    <dc:date>2013-03-30T13:21:47+00:00</dc:date>
    <link>http://arxiv.org/abs/1303.6020</link>
    <dc:creator>Vaguery</dc:creator><description><![CDATA[This paper proposes a novel generalization of group testing, called multi-group testing, which relaxes the notion of "testing subset" in group testing to "testing multi-set". The generalization aims to learn more information of each item to be tested rather than identify only defectives as was done in conventional group testing. This paper provides efficient nonadaptive strategies for the multi-group testing problem. The major tool is a new structure, $q$-ary additive $(w,d)$-disjunct matrix, which is a generalization of the well-known binary disjunct matrix introduced by Kautz and Singleton in 1964.]]></description>
<dc:subject>experimental-design testing statistics inference nudge-targets algorithms</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:Vaguery/b:bce834e4fce6/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:experimental-design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:statistics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:inference"/>
	<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/1302.0189">
    <title>[1302.0189] Non-adaptive pooling strategies for detection of rare faulty items</title>
    <dc:date>2013-03-18T16:01:22+00:00</dc:date>
    <link>http://arxiv.org/abs/1302.0189</link>
    <dc:creator>Vaguery</dc:creator><description><![CDATA[We study non-adaptive pooling strategies for detection of rare faulty items. Given a binary sparse N-dimensional signal x, how to construct a sparse binary MxN pooling matrix F such that the signal can be reconstructed from the smallest possible number M of measurements y=Fx? We show that a very low number of measurements is possible for random spatially coupled design of pools F. Our design might find application in genetic screening or compressed genotyping. We show that our results are robust with respect to the uncertainty in the matrix F when some elements are mistaken]]></description>
<dc:subject>testing engineering algorithms nudge-targets optimization</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:Vaguery/b:104ac85c8157/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:engineering"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:algorithms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:nudge-targets"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:optimization"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://bradfrostweb.com/demo/ish/">
    <title>ish. yet another viewport resizer.</title>
    <dc:date>2013-03-16T01:25:57+00:00</dc:date>
    <link>http://bradfrostweb.com/demo/ish/</link>
    <dc:creator>Vaguery</dc:creator><dc:subject>via:devonpersing web-design responsive-design testing user-experience</dc:subject>
<dc:identifier>https://pinboard.in/u:Vaguery/b:013881c8a98a/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:via:devonpersing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:web-design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:responsive-design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:user-experience"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://arxiv.org/abs/1212.1791">
    <title>[1212.1791] Generative Models for Functional Data using Phase and Amplitude Separation</title>
    <dc:date>2013-03-06T16:22:59+00:00</dc:date>
    <link>http://arxiv.org/abs/1212.1791</link>
    <dc:creator>Vaguery</dc:creator><description><![CDATA[Constructing generative models for functional observations is an important task in statistical functional analysis. In general, functional data contains both phase (or x or horizontal) and amplitude (or y or vertical) variability. Tradi- tional methods often ignore the phase variability and focus solely on the amplitude variation, using cross-sectional techniques such as fPCA for dimensional reduction and data modeling. Ignoring phase variability leads to a loss of structure in the data and inefficiency in data models. This paper presents an approach that relies on separating the phase (x-axis) and amplitude (y-axis), then modeling these components using joint distributions. This separation, in turn, is performed using a technique called elastic shape analysis of curves that involves a new mathematical representation of functional data. Then, using individual fPCAs, one each for phase and amplitude components, while respecting the nonlinear geometry of the phase representation space; impose joint probability models on principal coefficients of these components. These ideas are demonstrated using random sampling, for models estimated from simulated and real datasets, and show their superiority over models that ignore phase-amplitude separation. Furthermore, the generative models are applied to classification of functional data and achieve high performance in applications involv- ing SONAR signals of underwater objects, handwritten signatures, and periodic body movements recorded by smart phones.]]></description>
<dc:subject>simulation simulated-data resampling testing inverse-problems nudge-targets algorithms</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:Vaguery/b:ef2e7ceded1a/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:simulation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:simulated-data"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:resampling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:inverse-problems"/>
	<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://betterspecs.org/">
    <title>Better Specs</title>
    <dc:date>2012-10-19T12:54:57+00:00</dc:date>
    <link>http://betterspecs.org/</link>
    <dc:creator>Vaguery</dc:creator><description><![CDATA[RSpec is a great tool in the behavior driven design process of writing human readable specifications that direct and validate the development of your application.

On the web you can find several resources explaining how to use RSpec and they all give you a complete overview of what you can do. What you'll rarely find is a book or an article explaining how to use RSpec to create a great test suite.

Better Specs tries to fill this miss collecting most of the guidelines developers has been learning the hard way through years of experience.

]]></description>
<dc:subject>rspec programming software-development testing advice style</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:Vaguery/b:8c4bee80da2c/</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:programming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:software-development"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:advice"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:style"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://arxiv.org/abs/1208.3337">
    <title>[1208.3337] What Good Are Strong Specifications?</title>
    <dc:date>2012-08-22T15:41:28+00:00</dc:date>
    <link>http://arxiv.org/abs/1208.3337</link>
    <dc:creator>Vaguery</dc:creator><description><![CDATA["Experience with lightweight formal methods suggests that programmers are willing to write specification if it brings tangible benefits to their usual development activities. This paper considers stronger specifications and studies whether they can be deployed as an incremental practice that brings additional benefits without being unacceptably expensive. We introduce a methodology that extends Design by Contract to write strong specifications of functional properties in the form of preconditions, postconditions, and invariants. The methodology aims at being palatable to developers who are not fluent in formal techniques but are comfortable with writing simple specifications. We evaluate the cost and the benefits of using strong specifications by applying the methodology to testing data structure implementations written in Eiffel and C#. In our extensive experiments, testing against strong specifications detects twice as many bugs as standard contracts, with a reasonable overhead in terms of annotation burden and runtime performance while testing. In the wide spectrum of formal techniques for software quality, testing against strong specifications lies in a "sweet spot" with a favorable benefit to effort ratio."]]></description>
<dc:subject>testing software-development cultural-assumptions idea-looking-pretty-good-next-to-a-straw-man</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:Vaguery/b:cef727934a3e/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:software-development"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:cultural-assumptions"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:idea-looking-pretty-good-next-to-a-straw-man"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://thechangelog.com/post/388235527/aruby-cucumber-from-the-command-line">
    <title>aruba - Cucumber steps for testing your command line apps - The Changelog - Open Source moves fast. Keep up.</title>
    <dc:date>2010-09-15T10:24:41+00:00</dc:date>
    <link>http://thechangelog.com/post/388235527/aruby-cucumber-from-the-command-line</link>
    <dc:creator>Vaguery</dc:creator><description><![CDATA["Terminal junkies rejoice! Now you can use Cucumber to test your command line interfaces just like you do for your web apps.…"
]]></description>
<dc:subject>ruby command-line cucumber testing bdd</dc:subject>
<dc:identifier>https://pinboard.in/u:Vaguery/b:b38601935e4c/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:ruby"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:command-line"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:cucumber"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:bdd"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://arxiv.org/abs/1007.3712">
    <title>[1007.3712] Formal Verification of Self-Assembling Systems</title>
    <dc:date>2010-07-26T13:04:58+00:00</dc:date>
    <link>http://arxiv.org/abs/1007.3712</link>
    <dc:creator>Vaguery</dc:creator><description><![CDATA["This paper introduces the theory and practice of formal verification of self-assembling systems. We interpret a well-studied abstraction of nanomolecular self assembly, the Abstract Tile Assembly Model (aTAM), into Computation Tree Logic (CTL), a temporal logic often used in model checking. We then consider the class of "rectilinear" tile assembly systems. This class includes most aTAM systems studied in the theoretical literature, and all (algorithmic) DNA tile self-assembling systems that have been realized in laboratories to date. We present a polynomial-time algorithm that, given a tile assembly system T as input, either provides a counterexample to T's rectilinearity or verifies whether T has a unique terminal assembly. …"
]]></description>
<dc:subject>self-assembly nanotechnology emergent-design molecular-design molecular-machinery engineering-design testing</dc:subject>
<dc:identifier>https://pinboard.in/u:Vaguery/b:1487dcb6313c/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:self-assembly"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:nanotechnology"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:emergent-design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:molecular-design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:molecular-machinery"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:engineering-design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:testing"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://testobsessed.com/wordpress/wp-content/uploads/2007/02/testheuristicscheatsheetv1.pdf">
    <title>TEST HEURISTICS CHEAT SHEET [pdf]</title>
    <dc:date>2010-06-05T21:10:55+00:00</dc:date>
    <link>http://testobsessed.com/wordpress/wp-content/uploads/2007/02/testheuristicscheatsheetv1.pdf</link>
    <dc:creator>Vaguery</dc:creator><dc:subject>agile-practices testing software-development hints agility best-practices</dc:subject>
<dc:identifier>https://pinboard.in/u:Vaguery/b:64c2e4906aed/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:agile-practices"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:software-development"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:hints"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:agility"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:best-practices"/>
</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://www.threeriversinstitute.org/blog/?p=494">
    <title>Three Rivers Institute » Blog Archive » Capital-Efficient UI Design</title>
    <dc:date>2010-04-28T15:26:26+00:00</dc:date>
    <link>http://www.threeriversinstitute.org/blog/?p=494</link>
    <dc:creator>Vaguery</dc:creator><description><![CDATA["Yesterday I started using two services, UserTesting.com and fivesecondtest.com, that bring the same capital- and time-efficiency to UI design that open source tools brought to programming. Rather than work extremely hard getting the design right, then failing if you guess wrong, it is now quick and cheap to iterate. Have a crazy idea? Test it. Three alternatives? Test them."
]]></description>
<dc:subject>user-experience testing web-design SAAS user-interface</dc:subject>
<dc:identifier>https://pinboard.in/u:Vaguery/b:a9645d82b95a/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:user-experience"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:web-design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:SAAS"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:user-interface"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://gojko.net/2010/04/28/acceptance-tests-are-not-a-by-product-of-development/">
    <title>Gojko Adzic » Acceptance tests are not a by-product of development</title>
    <dc:date>2010-04-28T15:13:04+00:00</dc:date>
    <link>http://gojko.net/2010/04/28/acceptance-tests-are-not-a-by-product-of-development/</link>
    <dc:creator>Vaguery</dc:creator><description><![CDATA["If we think about tests as by-products of the development process, this investment is very hard to justify because it doesn’t give direct value to any of the project stakeholders. The stakeholders of the framework, however, aren’t the customers or the business users. They are the members of the development teams (and maintenance teams if separate). Many teams I interviewed have at some point ripped out the heart of their system and replaced it, or rewritten the entire system, while keeping their acceptance tests and using them to guide the whole effort. This is where the investment in live documentation really pays off. Such a framework is genuinely a separate product, with a different lifecycle and a different group of stakeholders."
]]></description>
<dc:subject>documentation software-development software-development-is-not-programming cucmber testing acceptance-testing</dc:subject>
<dc:identifier>https://pinboard.in/u:Vaguery/b:7fa6c79248e3/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:documentation"/>
	<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:cucmber"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:acceptance-testing"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://github.com/cavalle/steak">
    <title>cavalle's steak at master - GitHub</title>
    <dc:date>2010-04-28T15:00:00+00:00</dc:date>
    <link>http://github.com/cavalle/steak</link>
    <dc:creator>Vaguery</dc:creator><description><![CDATA["Minimalist acceptance testing on top of RSpec"
]]></description>
<dc:subject>acceptance-testing rspec ruby development BDD testing scripting</dc:subject>
<dc:identifier>https://pinboard.in/u:Vaguery/b:2b5f4f0cc73b/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:acceptance-testing"/>
	<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:development"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:BDD"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:scripting"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://blog.orfjackal.net/2010/04/direct-and-indirect-effects-of-tdd.html">
    <title>Random Thoughts from Esko: Direct and Indirect Effects of TDD</title>
    <dc:date>2010-04-11T12:16:57+00:00</dc:date>
    <link>http://blog.orfjackal.net/2010/04/direct-and-indirect-effects-of-tdd.html</link>
    <dc:creator>Vaguery</dc:creator><description><![CDATA["Noticing the pain as soon as possible and then fixing the problem - whether it is a rigid design, fragile tests or something else - requires skill. Not everybody is alert to the pain, but instead they keep on writing bad code until making changes becomes too expensive and a rewrite is needed. Not everybody fixes the problem when they feel the pain, but instead they implement a quick hack and leave an even bigger mess for the next developer. But for those who have the necessary skills and discipline, TDD can be a powerful tool and they can use it to write better code."
]]></description>
<dc:subject>tdd agile-practices software-development testing social-engineering good-habits</dc:subject>
<dc:identifier>https://pinboard.in/u:Vaguery/b:a137eca376df/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:tdd"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:agile-practices"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:software-development"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:social-engineering"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:good-habits"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://cannedcukes.heroku.com/">
    <title>CannedCukes - Awesome Feature Hosting</title>
    <dc:date>2010-04-05T18:52:05+00:00</dc:date>
    <link>http://cannedcukes.heroku.com/</link>
    <dc:creator>Vaguery</dc:creator><description><![CDATA["CannedCukes is all about one thing: helping people make better BDD tests. CannedCukes is a place where BDD testers from across the world can upload Cucumber features and scenarios and share them with other testers."
]]></description>
<dc:subject>good-ideas cucumber BDD testing Ruby community should-be-open-though</dc:subject>
<dc:identifier>https://pinboard.in/u:Vaguery/b:1e8b0e334ed2/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:good-ideas"/>
	<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:testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:Ruby"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:community"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:should-be-open-though"/>
</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://blog.webbynode.com/2009/11/07/reusing-webrat-matchers-for-html-validation-in-cucumber/">
    <title>Webbynode</title>
    <dc:date>2009-11-08T20:02:19+00:00</dc:date>
    <link>http://blog.webbynode.com/2009/11/07/reusing-webrat-matchers-for-html-validation-in-cucumber/</link>
    <dc:creator>Vaguery</dc:creator><description><![CDATA["Recently here at Webbynode we had a demand for validating HTML without going as far as driving a browser. We have an internal library that generates HTML after compiling HAML templates. To fulfill our BDD needs, we wanted a simple, straightforward way to validate HTML tags without the need of a full blown browser driving engine, since we don’t have an HTTP server running while testing this library."
]]></description>
<dc:subject>BDD Rails WebRat cucumber testing programming Ruby</dc:subject>
<dc:identifier>https://pinboard.in/u:Vaguery/b:6f0b583294b9/</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:Rails"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:WebRat"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:cucumber"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:programming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:Ruby"/>
</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://www.getwindmill.com/">
    <title>Windmill Testing Framework</title>
    <dc:date>2009-06-24T10:01:58+00:00</dc:date>
    <link>http://www.getwindmill.com/</link>
    <dc:creator>Vaguery</dc:creator><dc:subject>via:jayturley testing browsers cross-browser-testing acceptance-testing integration-testing tool library web-design</dc:subject>
<dc:identifier>https://pinboard.in/u:Vaguery/b:9bc6a3459115/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:via:jayturley"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:browsers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:cross-browser-testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:acceptance-testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:integration-testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:tool"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:library"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:web-design"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://railscasts.com/episodes/166-metric-fu">
    <title>Railscasts - Metric Fu</title>
    <dc:date>2009-06-15T11:55:05+00:00</dc:date>
    <link>http://railscasts.com/episodes/166-metric-fu</link>
    <dc:creator>Vaguery</dc:creator><description><![CDATA["Metric Fu is a compilation of several tools to help find areas of code that could be improved. In this episode I show you how to setup this tool on the railscasts.com source code."
]]></description>
<dc:subject>Rails programming profiling optimization testing software software-development</dc:subject>
<dc:identifier>https://pinboard.in/u:Vaguery/b:6073705e3300/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:Rails"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:programming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:profiling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:software"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:software-development"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.pathf.com/blogs/2009/05/rails-testing-frequently-asked-questions-the-non-code-version/">
    <title>Agile Ajax » Rails Testing Frequently Asked Questions — The Non-Code Version » Pathfinder Development</title>
    <dc:date>2009-05-20T21:41:04+00:00</dc:date>
    <link>http://www.pathf.com/blogs/2009/05/rails-testing-frequently-asked-questions-the-non-code-version/</link>
    <dc:creator>Vaguery</dc:creator><description><![CDATA["Things to keep in mind.

No matter where you start, start with one simple test. One assertion, if you can manage it.
Write the code to make that test pass
Then refactor -- this part is critical, this is where the creative design is with a TDD process.
Then write the next test.
In Rails, you'll often start in the controller then realize that code needs to be written in the model (or vice-versa). Write a separate test for the model -- testing models from the controller makes it hard to test all the model logic.
It's okay to plan the tests in advance, but you should only work on one test at a time. (Sometimes I'll write the series of tests, then comment out all but one)"
]]></description>
<dc:subject>test-driven-development TDD testing Rails Ruby programming-culture advice getting-hired</dc:subject>
<dc:identifier>https://pinboard.in/u:Vaguery/b:385e3ed40e2a/</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:testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:Rails"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:Ruby"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:programming-culture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:advice"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:getting-hired"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://fakeweb.rubyforge.org/">
    <title>FakeWeb API Documentation</title>
    <dc:date>2009-04-19T23:25:22+00:00</dc:date>
    <link>http://fakeweb.rubyforge.org/</link>
    <dc:creator>Vaguery</dc:creator><description><![CDATA["FakeWeb is a helper for faking web requests in Ruby. It works at a global level, without modifying code or writing extensive stubs."
]]></description>
<dc:subject>Ruby programming mocks-and-stubs TDD BDD development testing</dc:subject>
<dc:identifier>https://pinboard.in/u:Vaguery/b:b2e38b7a0a3e/</dc:identifier>
<taxo:topics><rdf:Bag>	<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:mocks-and-stubs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:TDD"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:BDD"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:development"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:testing"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://xunitpatterns.com/Test%20Stub.html">
    <title>Test Stub at XUnitPatterns.com</title>
    <dc:date>2009-04-15T03:05:54+00:00</dc:date>
    <link>http://xunitpatterns.com/Test%20Stub.html</link>
    <dc:creator>Vaguery</dc:creator><description><![CDATA["Variation: Saboteur
A Test Stub that is used to inject invalid indirect inputs into the SUT is often called a "Saboteur" because its purpose is to derail whatever the SUT is trying to do so we can see how the SUT copes with these circumstances. The "derailment" can be caused by returning unexpected values or objects, or it can be caused by raising an exception or causing a runtime error. Each test may either be a Simple Success Test or an Expected Exception Test (see Test Method) depending on how the SUT is expected to behave in response to the indirect input."
]]></description>
<dc:subject>testing TDD BDD rspec design-patterns programming unit-testing specification</dc:subject>
<dc:identifier>https://pinboard.in/u:Vaguery/b:5d91f36cefc5/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:TDD"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:BDD"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:rspec"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:design-patterns"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:programming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:unit-testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:specification"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://github.com/btakita/rr/tree/master">
    <title>btakita's rr at master - GitHub</title>
    <dc:date>2009-04-15T02:59:18+00:00</dc:date>
    <link>http://github.com/btakita/rr/tree/master</link>
    <dc:creator>Vaguery</dc:creator><description><![CDATA["RR (Double Ruby) is a test double framework that features a rich selection of double techniques and a terse syntax."
]]></description>
<dc:subject>mocks programming testing TDD BDD rspec framework ruby</dc:subject>
<dc:identifier>https://pinboard.in/u:Vaguery/b:d4177fe4df36/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:mocks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:programming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:TDD"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:BDD"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:rspec"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:framework"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:ruby"/>
</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://timothyfitz.wordpress.com/2009/02/08/continuous-deployment/">
    <title>Continuous Deployment « Timothy Fitz</title>
    <dc:date>2009-02-27T12:13:29+00:00</dc:date>
    <link>http://timothyfitz.wordpress.com/2009/02/08/continuous-deployment/</link>
    <dc:creator>Vaguery</dc:creator><description><![CDATA["So what should Alex do? Continuously deploy. Every commit should be instantly deployed to production. Let’s walk through her story again, assuming she had such an ideal implementation of Continuous Deployment.
Alex commits. Minutes later warnings go off that the cluster is no longer healthy. The failure is easily correlated to Alex’s change and her change is reverted. Alex spends minimal time debugging, finding the now obvious typo with ease. Her changes still caused a failure cascade, but the downtime was minimal. "
]]></description>
<dc:subject>continuous-integration continuous-deployment testing agility FUD amusing-comments</dc:subject>
<dc:identifier>https://pinboard.in/u:Vaguery/b:1cd856b32230/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:continuous-integration"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:continuous-deployment"/>
	<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:FUD"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:amusing-comments"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://startuplessonslearned.blogspot.com/2009/02/continuous-deployment-and-continuous.html">
    <title>Lessons Learned: Continuous deployment and continuous learning</title>
    <dc:date>2009-02-27T12:11:12+00:00</dc:date>
    <link>http://startuplessonslearned.blogspot.com/2009/02/continuous-deployment-and-continuous.html</link>
    <dc:creator>Vaguery</dc:creator><description><![CDATA["Assuming you're with me so far, what will that mean in practice? Throwing out a lot of code. That's because as you get better at continuous deployment, you learn more and more about what works and what doesn't. If you're serious about learning, you'll continuously learn to prune the dead weight that doesn't work. That's not entirely without risk, which is a lesson we learned all-too-well at IMVU. Luckily, Chad Austin has recently weighed in with an excellent piece called 10 Pitfalls of Dirty Code."
]]></description>
<dc:subject>programming software-development continuous-integration agility release-schedule production testing</dc:subject>
<dc:identifier>https://pinboard.in/u:Vaguery/b:194a1e4cf3e0/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:programming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:software-development"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:continuous-integration"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:agility"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:release-schedule"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:production"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:testing"/>
</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://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://ericholscher.com/tag/testing-series/">
    <title>Post archive | Surfing in Kansas</title>
    <dc:date>2008-12-17T00:25:34+00:00</dc:date>
    <link>http://ericholscher.com/tag/testing-series/</link>
    <dc:creator>Vaguery</dc:creator><dc:subject>via:arsyed Python testing Django TDD (?)</dc:subject>
<dc:identifier>https://pinboard.in/u:Vaguery/b:70bd8e29a3e9/</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:Python"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:Django"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:TDD"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:(?)"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.voidspace.org.uk/python/mock.html">
    <title>Mock - Mocking and Test Utilities</title>
    <dc:date>2008-10-20T14:29:38+00:00</dc:date>
    <link>http://www.voidspace.org.uk/python/mock.html</link>
    <dc:creator>Vaguery</dc:creator><dc:subject>programming development library tools Python testing TDD agility</dc:subject>
<dc:identifier>https://pinboard.in/u:Vaguery/b:818b83e99f7a/</dc:identifier>
<taxo:topics><rdf:Bag>	<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:library"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:tools"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:Python"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:TDD"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:agility"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://broadband.mpi-sws.mpg.de/transparency/bttest.php">
    <title>Glasnost: Test if your ISP is manipulating BitTorrent traffic</title>
    <dc:date>2008-06-30T12:03:26+00:00</dc:date>
    <link>http://broadband.mpi-sws.mpg.de/transparency/bttest.php</link>
    <dc:creator>Vaguery</dc:creator><dc:subject>via:arsyed broadband bittorrent openness service-providers Internet Netneutrality p2p testing speed</dc:subject>
<dc:identifier>https://pinboard.in/u:Vaguery/b:6a7338f0a3c0/</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:broadband"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:bittorrent"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:openness"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:service-providers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:Internet"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:Netneutrality"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:p2p"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:speed"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://crookedtimber.org/2008/06/07/the-perfect-exam-paper/">
    <title>Crooked Timber » » The perfect exam paper</title>
    <dc:date>2008-06-08T13:35:22+00:00</dc:date>
    <link>http://crookedtimber.org/2008/06/07/the-perfect-exam-paper/</link>
    <dc:creator>Vaguery</dc:creator><description><![CDATA[Also may be useful in biology and biochemistry, amazingly enough.
]]></description>
<dc:subject>pedagogy damned-kids academia teaching testing writing wet-paper-bag</dc:subject>
<dc:identifier>https://pinboard.in/u:Vaguery/b:d7256a801d0a/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:pedagogy"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:damned-kids"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:academia"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:teaching"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:writing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:wet-paper-bag"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://blog.davidchelimsky.net/articles/2008/05/27/rspec-1-1-4">
    <title>RSpec-1.1.4</title>
    <dc:date>2008-05-27T10:56:09+00:00</dc:date>
    <link>http://blog.davidchelimsky.net/articles/2008/05/27/rspec-1-1-4</link>
    <dc:creator>Vaguery</dc:creator><dc:subject>rspec BDD Rails testing update</dc:subject>
<dc:identifier>https://pinboard.in/u:Vaguery/b:1bfff0fb259a/</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:Rails"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:update"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://rubyphunk.com/2008/4/28/ann-rspactor-0-9-10-some-people-call-it-beta">
    <title>rubyphunk - ANN: RSpactor 0.9.10 (aka. beta)</title>
    <dc:date>2008-05-10T12:09:43+00:00</dc:date>
    <link>http://rubyphunk.com/2008/4/28/ann-rspactor-0-9-10-some-people-call-it-beta</link>
    <dc:creator>Vaguery</dc:creator><dc:subject>rspec BDD osx programming Rails Ruby testing</dc:subject>
<dc:identifier>https://pinboard.in/u:Vaguery/b:489c7aa39e8c/</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:osx"/>
	<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:Ruby"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:testing"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://daveastels.com/index.php?p=5">
    <title>dave astels » Why Your Code Sucks</title>
    <dc:date>2008-04-26T12:55:43+00:00</dc:date>
    <link>http://daveastels.com/index.php?p=5</link>
    <dc:creator>Vaguery</dc:creator><description><![CDATA[Just worth posting on the wall, is all.
]]></description>
<dc:subject>rules agility programming software development coding design testing TDD BDD</dc:subject>
<dc:identifier>https://pinboard.in/u:Vaguery/b:eed0f2ad952f/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:rules"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:agility"/>
	<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:li rdf:resource="https://pinboard.in/u:Vaguery/t:coding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:TDD"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:BDD"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://peripateticaxiom.blogspot.com/2006/05/complexity-and-test-first-0.html">
    <title>peripatetic axiom: Complexity and Test-first 0</title>
    <dc:date>2008-02-19T01:43:16+00:00</dc:date>
    <link>http://peripateticaxiom.blogspot.com/2006/05/complexity-and-test-first-0.html</link>
    <dc:creator>Vaguery</dc:creator><dc:subject>testing software development TDD agility metrics quality</dc:subject>
<dc:identifier>https://pinboard.in/u:Vaguery/b:13380bb53d3f/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:testing"/>
	<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:TDD"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:agility"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:metrics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:quality"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.isri.unlv.edu/ISRI/OCRtk">
    <title>OCRtk</title>
    <dc:date>2008-02-11T04:18:23+00:00</dc:date>
    <link>http://www.isri.unlv.edu/ISRI/OCRtk</link>
    <dc:creator>Vaguery</dc:creator><dc:subject>OCR testing digitization standards</dc:subject>
<dc:identifier>https://pinboard.in/u:Vaguery/b:e43013db1642/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:OCR"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:digitization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:standards"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://rspec.rubyforge.org/">
    <title>RSpec-1.0.8: Home</title>
    <dc:date>2007-11-18T19:10:43+00:00</dc:date>
    <link>http://rspec.rubyforge.org/</link>
    <dc:creator>Vaguery</dc:creator><dc:subject>extreme-programming agile BDD development documentation engineering programming Rails Ruby rubyonrails TDD testing</dc:subject>
<dc:identifier>https://pinboard.in/u:Vaguery/b:d8453afe9446/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:extreme-programming"/>
	<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:development"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:documentation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:engineering"/>
	<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:Ruby"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:rubyonrails"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:TDD"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:testing"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.pgdp.net/c/faq/ppv.php#checks">
    <title>DP: Post-Processing Verification Guidelines</title>
    <dc:date>2007-11-12T12:44:34+00:00</dc:date>
    <link>http://www.pgdp.net/c/faq/ppv.php#checks</link>
    <dc:creator>Vaguery</dc:creator><description><![CDATA[Useful starting point for my acceptance testing list. Noted PPV report, which is a real acceptance test based on subjective estimates; could that be fleshed out?
]]></description>
<dc:subject>Distributed-Proofreaders post-processing ebooks digitization workflow standardization testing benchmarking</dc:subject>
<dc:identifier>https://pinboard.in/u:Vaguery/b:9c8d05bf9a0b/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:Distributed-Proofreaders"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:post-processing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:ebooks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:digitization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:workflow"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:standardization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:benchmarking"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.philol.msu.ru/~otipl/new/main/mol/samples-2003-en.php">
    <title>Sample linguistic problems :: МГУ :: Филфак :: ОТиПЛ</title>
    <dc:date>2007-08-26T13:46:41+00:00</dc:date>
    <link>http://www.philol.msu.ru/~otipl/new/main/mol/samples-2003-en.php</link>
    <dc:creator>Vaguery</dc:creator><description><![CDATA[via rfrank at the Distributed Proofreaders community
]]></description>
<dc:subject>linguistics testing problems challenges Olympiad questions explanation answer-key</dc:subject>
<dc:identifier>https://pinboard.in/u:Vaguery/b:7f3094b4627e/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:linguistics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:problems"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:challenges"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:Olympiad"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:questions"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:explanation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:answer-key"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://blog.objectmentor.com/articles/2007/06/20/creationism-versus-natural-selection">
    <title>Creationism versus Natural Selection</title>
    <dc:date>2007-08-03T20:37:01+00:00</dc:date>
    <link>http://blog.objectmentor.com/articles/2007/06/20/creationism-versus-natural-selection</link>
    <dc:creator>Vaguery</dc:creator><description><![CDATA["In the beginning, the Product Owner identified a Need. And the Need was without form, and void; and darkness was upon the face of the deep. And the Spirit of the Team (Team) moved upon the face of the Need and asked some questions."
]]></description>
<dc:subject>TDD testing software development methodologies rigor</dc:subject>
<dc:identifier>https://pinboard.in/u:Vaguery/b:dbfb0df2ae2b/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:TDD"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:testing"/>
	<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:methodologies"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:rigor"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.opentick.com/">
    <title>opentick :: home</title>
    <dc:date>2007-05-29T12:42:09+00:00</dc:date>
    <link>http://www.opentick.com/</link>
    <dc:creator>Vaguery</dc:creator><description><![CDATA[Historical market data source.
]]></description>
<dc:subject>automation testing software prediction market finance development statistics genetic-programming data archive</dc:subject>
<dc:identifier>https://pinboard.in/u:Vaguery/b:c26f27ba741b/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:automation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:software"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:prediction"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:market"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:finance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:development"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:statistics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:genetic-programming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:data"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:archive"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://vitalbrew.blogspot.com/2006/03/emergent-documentation.html">
    <title>vitalbrew.com: Emergent Documentation</title>
    <dc:date>2007-04-19T03:58:21+00:00</dc:date>
    <link>http://vitalbrew.blogspot.com/2006/03/emergent-documentation.html</link>
    <dc:creator>Vaguery</dc:creator><dc:subject>agility technical writing documentation collaboration testing coauthorship</dc:subject>
<dc:identifier>https://pinboard.in/u:Vaguery/b:779f6551f13d/</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:technical"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:writing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:documentation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:collaboration"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:coauthorship"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://nunit.com/nunit/?p=releaseNotes&amp;r=2.4">
    <title>NUnit - ReleaseNotes</title>
    <dc:date>2007-03-03T14:45:49+00:00</dc:date>
    <link>http://nunit.com/nunit/?p=releaseNotes&amp;r=2.4</link>
    <dc:creator>Vaguery</dc:creator><description><![CDATA[New version of NUnit testing framework is released.
]]></description>
<dc:subject>software development agile XP unit-testing TDD testing programming</dc:subject>
<dc:identifier>https://pinboard.in/u:Vaguery/b:faecbd77844d/</dc:identifier>
<taxo:topics><rdf:Bag>	<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:agile"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:XP"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:unit-testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:TDD"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:programming"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://blog.daveastels.com/files/BDD_Intro.pdf">
    <title>BDD_Intro.pdf (application/pdf Object)</title>
    <dc:date>2007-03-01T02:19:43+00:00</dc:date>
    <link>http://blog.daveastels.com/files/BDD_Intro.pdf</link>
    <dc:creator>Vaguery</dc:creator><dc:subject>BDD Ruby software development design TDD testing programming</dc:subject>
<dc:identifier>https://pinboard.in/u:Vaguery/b:bfdc9f07fe2b/</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:Ruby"/>
	<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:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:TDD"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:programming"/>
</rdf:Bag></taxo:topics>
</item>
</rdf:RDF>