<?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://blog.acolyer.org/2019/06/03/ease-ml-ci/"/>
	<rdf:li rdf:resource="http://khanlou.com/2019/07/continuous-integration/"/>
	<rdf:li rdf:resource="http://arxiv.org/abs/1505.04112"/>
	<rdf:li rdf:resource="http://www.bigvisible.com/asroka/informative-build/"/>
	<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:Seq>
    </items>
  </channel><item rdf:about="https://blog.acolyer.org/2019/06/03/ease-ml-ci/">
    <title>Continuous integration of machine learning models with ease.ml/ci | the morning paper</title>
    <dc:date>2021-03-18T20:23:54+00:00</dc:date>
    <link>https://blog.acolyer.org/2019/06/03/ease-ml-ci/</link>
    <dc:creator>Vaguery</dc:creator><description><![CDATA[The tricky parts then, are (a) figuring out how many samples you need to achieve a given level of  reliability, (b) trying to keep that number as low as possible to minimise the data labelling / gathering requirements, and (c ) working out how many CI tests you can do with a given set of samples before they need to be refreshed.

]]></description>
<dc:subject>machine-learning software-development continuous-integration training rather-interesting software-engineering using-the-tools-at-hand</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:Vaguery/b:6e642d5c088a/</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:software-development"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:continuous-integration"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:training"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:rather-interesting"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:software-engineering"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:using-the-tools-at-hand"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://khanlou.com/2019/07/continuous-integration/">
    <title>Khanlou | Continuous Integration</title>
    <dc:date>2019-08-18T11:54:16+00:00</dc:date>
    <link>http://khanlou.com/2019/07/continuous-integration/</link>
    <dc:creator>Vaguery</dc:creator><description><![CDATA[Code that isn’t integrated into your team’s mainline branch should be considered a liability at best, and dead at worst. Your job is to get the small, workable units of code merged in as early as possible.

]]></description>
<dc:subject>continuous-integration software-development-is-not-programming collaboration rapid-feedback to-write-about academic-culture</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:Vaguery/b:5435d6dcf4af/</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:software-development-is-not-programming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:collaboration"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:rapid-feedback"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:to-write-about"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:academic-culture"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://arxiv.org/abs/1505.04112">
    <title>[1505.04112] How, What and Why to test an ontology</title>
    <dc:date>2015-06-20T12:18:21+00:00</dc:date>
    <link>http://arxiv.org/abs/1505.04112</link>
    <dc:creator>Vaguery</dc:creator><description><![CDATA[Ontology development relates to software development in that they both involve the production of formal computational knowledge. It is possible, therefore, that some of the techniques used in software engineering could also be used for ontologies; for example, in software engineering testing is a well-established process, and part of many different methodologies. 
The application of testing to ontologies, therefore, seems attractive. The Karyotype Ontology is developed using the novel Tawny-OWL library. This provides a fully programmatic environment for ontology development, which includes a complete test harness. 
In this paper, we describe how we have used this harness to build an extensive series of tests as well as used a commodity continuous integration system to link testing deeply into our development process; this environment, is applicable to any OWL ontology whether written using Tawny-OWL or not. Moreover, we present a novel analysis of our tests, introducing a new classification of what our different tests are. For each class of test, we describe why we use these tests, also by comparison to software tests. We believe that this systematic comparison between ontology and software development will help us move to a more agile form of ontology development.
]]></description>
<dc:subject>ontology test-driven-development rather-interesting continuous-integration travis-ci bioinformatics logic-programming the-mangle-in-practice</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:Vaguery/b:1fb8f4918a90/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:ontology"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:test-driven-development"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:rather-interesting"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:continuous-integration"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:travis-ci"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:bioinformatics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:logic-programming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:the-mangle-in-practice"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.bigvisible.com/asroka/informative-build/">
    <title>Informative Build | bigvisible.com</title>
    <dc:date>2009-11-08T19:48:22+00:00</dc:date>
    <link>http://www.bigvisible.com/asroka/informative-build/</link>
    <dc:creator>Vaguery</dc:creator><description><![CDATA["An Informative Build is a build that tells us what the state of our development is so that we can make an informed decision. We need an informative build, because otherwise Continuous Integration is just a waste of our time.

That’s right, I said Continuous Integration is a waste of time. It is a waste of time, because simply running a build doesn’t help us unless that build can also tell us what we need to do. An Informative Build:

Fails when something is wrong, letting us know that our system is broken and we must fix it.
When it fails it tells us precisely why it failed so that we know what we have to do to fix it.
When nothing is wrong it doesn’t fail. We shouldn’t be wasting cycles chasing down errors due to brittle tests or external dependencies."
]]></description>
<dc:subject>continuous-integration extreme-programming agility practice test-driven-development test-driven-design productivity software-development mythology</dc:subject>
<dc:identifier>https://pinboard.in/u:Vaguery/b:1d57f5c7cf8b/</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:extreme-programming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:agility"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:practice"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:test-driven-development"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:test-driven-design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:productivity"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:software-development"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:mythology"/>
</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>
</rdf:RDF>