<?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/2101.10087"/>
	<rdf:li rdf:resource="https://arxiv.org/abs/2001.11334"/>
	<rdf:li rdf:resource="https://blog.acolyer.org/2019/06/03/ease-ml-ci/"/>
	<rdf:li rdf:resource="https://arxiv.org/abs/1812.07270"/>
	<rdf:li rdf:resource="https://arxiv.org/abs/1705.06640"/>
	<rdf:li rdf:resource="https://arxiv.org/abs/1810.04825"/>
	<rdf:li rdf:resource="https://arxiv.org/abs/1710.03720"/>
	<rdf:li rdf:resource="https://arxiv.org/abs/1703.10862"/>
	<rdf:li rdf:resource="http://arxiv.org/abs/1502.03526"/>
	<rdf:li rdf:resource="http://arxiv.org/abs/1410.6449"/>
	<rdf:li rdf:resource="http://arxiv.org/abs/1204.4224"/>
	<rdf:li rdf:resource="http://arxiv.org/abs/1205.5975"/>
	<rdf:li rdf:resource="http://engineering.twitter.com/2011/05/faster-ruby-kiji-update.html"/>
	<rdf:li rdf:resource="http://www2.computer.org/cms/Computer.org/ComputingNow/homepage/2009/0709/rW_SO_Viewpoints.pdf"/>
      </rdf:Seq>
    </items>
  </channel><item rdf:about="https://arxiv.org/abs/2101.10087">
    <title>[2101.10087] Automating Program Structure Classification</title>
    <dc:date>2022-02-08T12:26:52+00:00</dc:date>
    <link>https://arxiv.org/abs/2101.10087</link>
    <dc:creator>Vaguery</dc:creator><description><![CDATA[When students write programs, their program structure provides insight into their learning process. However, analyzing program structure by hand is time-consuming, and teachers need better tools for computer-assisted exploration of student solutions. As a first step towards an education-oriented program analysis toolkit, we show how supervised machine learning methods can automatically classify student programs into a predetermined set of high-level structures. We evaluate two models on classifying student solutions to the Rainfall problem: a nearest-neighbors classifier using syntax tree edit distance and a recurrent neural network. We demonstrate that these models can achieve 91% classification accuracy when trained on 108 programs. We further explore the generality, trade-offs, and failure cases of each model.
]]></description>
<dc:subject>strings software-engineering classification rather-interesting to-write-about consider:genetic-programming consider:clustering-ineffable-solutions</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:Vaguery/b:7a910b0aa8b4/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:strings"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:software-engineering"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:classification"/>
	<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:li rdf:resource="https://pinboard.in/u:Vaguery/t:consider:genetic-programming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:consider:clustering-ineffable-solutions"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://arxiv.org/abs/2001.11334">
    <title>[2001.11334] Why Should Anyone use Colours? or, Syntax Highlighting Beyond Code Snippets</title>
    <dc:date>2021-06-17T21:59:39+00:00</dc:date>
    <link>https://arxiv.org/abs/2001.11334</link>
    <dc:creator>Vaguery</dc:creator><description><![CDATA[Syntax highlighting in the form of colours and font diversification, is an excellent tool to provide clarity, concision and correctness to writings. Unfortunately, this practice is not widely adopted, which results in often hard-to-parse papers. The reasons for this lack of adoption is that researchers often struggle to embrace new technologies, piling up unconvincing motivations. This paper argues against such motivations and justifies the usage of syntax highlighting so that it can become a new standard for dissemination of clearer and more understandable research. Moreover, this paper reports on the criticism grounded on the shortcomings of using syntax highlighting in LATEX and suggests remedies to that. We believe this paper can be used as a guide to using syntax highlighting as well as a reference to counter unconvincing motivations against it.
]]></description>
<dc:subject>software-engineering usability accessibility rather-interesting LaTeX affordances ergonomics software-development-is-not-programming</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:Vaguery/b:e6a1ea36eb4c/</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:usability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:accessibility"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:rather-interesting"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:LaTeX"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:affordances"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:ergonomics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:software-development-is-not-programming"/>
</rdf:Bag></taxo:topics>
</item>
<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="https://arxiv.org/abs/1812.07270">
    <title>[1812.07270] AVATAR : Fixing Semantic Bugs with Fix Patterns of Static Analysis Violations</title>
    <dc:date>2020-03-20T16:38:42+00:00</dc:date>
    <link>https://arxiv.org/abs/1812.07270</link>
    <dc:creator>Vaguery</dc:creator><description><![CDATA[Fix pattern-based patch generation is a promising direction in Automated Program Repair (APR). Notably, it has been demonstrated to produce more acceptable and correct patches than the patches obtained with mutation operators through genetic programming. The performance of pattern-based APR systems, however, depends on the fix ingredients mined from fix changes in development histories. Unfortunately, collecting a reliable set of bug fixes in repositories can be challenging. In this paper, we propose to investigate the possibility in an APR scenario of leveraging code changes that address violations by static bug detection tools. To that end, we build the AVATAR APR system, which exploits fix patterns of static analysis violations as ingredients for patch generation. Evaluated on the Defects4J benchmark, we show that, assuming a perfect localization of faults, AVATAR can generate correct patches to fix 34/39 bugs. We further find that AVATAR yields performance metrics that are comparable to that of the closely-related approaches in the literature. While AVATAR outperforms many of the state-of-the-art pattern-based APR systems, it is mostly complementary to current approaches. Overall, our study highlights the relevance of static bug finding tools as indirect contributors of fix ingredients for addressing code defects identified with functional test cases.
]]></description>
<dc:subject>refactoring software-engineering performance-measure rather-interesting rewriting-systems to-download to-simulate consider:refactoring-as-such</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:Vaguery/b:be090c45941a/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:refactoring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:software-engineering"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:performance-measure"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:rather-interesting"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:rewriting-systems"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:to-download"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:to-simulate"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:consider:refactoring-as-such"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://arxiv.org/abs/1705.06640">
    <title>[1705.06640] DeepXplore: Automated Whitebox Testing of Deep Learning Systems</title>
    <dc:date>2019-04-24T14:10:41+00:00</dc:date>
    <link>https://arxiv.org/abs/1705.06640</link>
    <dc:creator>Vaguery</dc:creator><description><![CDATA[Deep learning (DL) systems are increasingly deployed in safety- and security-critical domains including self-driving cars and malware detection, where the correctness and predictability of a system's behavior for corner case inputs are of great importance. Existing DL testing depends heavily on manually labeled data and therefore often fails to expose erroneous behaviors for rare inputs. 
We design, implement, and evaluate DeepXplore, the first whitebox framework for systematically testing real-world DL systems. First, we introduce neuron coverage for systematically measuring the parts of a DL system exercised by test inputs. Next, we leverage multiple DL systems with similar functionality as cross-referencing oracles to avoid manual checking. Finally, we demonstrate how finding inputs for DL systems that both trigger many differential behaviors and achieve high neuron coverage can be represented as a joint optimization problem and solved efficiently using gradient-based search techniques. 
DeepXplore efficiently finds thousands of incorrect corner case behaviors (e.g., self-driving cars crashing into guard rails and malware masquerading as benign software) in state-of-the-art DL models with thousands of neurons trained on five popular datasets including ImageNet and Udacity self-driving challenge data. For all tested DL models, on average, DeepXplore generated one test input demonstrating incorrect behavior within one second while running only on a commodity laptop. We further show that the test inputs generated by DeepXplore can also be used to retrain the corresponding DL model to improve the model's accuracy by up to 3%.
]]></description>
<dc:subject>fuzz-testing stress-testing machine-learning neural-networks rather-interesting knobs-to-11 security software-engineering trustable-models to-write-about</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:Vaguery/b:c04d7d30b78b/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:fuzz-testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:stress-testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:machine-learning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:neural-networks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:rather-interesting"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:knobs-to-11"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:security"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:software-engineering"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:trustable-models"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:to-write-about"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://arxiv.org/abs/1810.04825">
    <title>[1810.04825] An Initial Step Towards Organ Transplantation Based on GitHub Repository</title>
    <dc:date>2018-12-24T01:08:06+00:00</dc:date>
    <link>https://arxiv.org/abs/1810.04825</link>
    <dc:creator>Vaguery</dc:creator><description><![CDATA[Organ transplantation, which is the utilization of codes directly related to some specific functionalities to complete ones own program, provides more convenience for developers than traditional component reuse. However, recent techniques are challenged with the lack of organs for transplantation. Hence, we conduct an empirical study on extracting organs from GitHub repository to explore transplantation based on large-scale dataset. We analyze statistics from 12 representative GitHub projects and get the conclusion that 1) there are abundant practical organs existing in commits with add as a key word in the comments; 2) organs in this repository mainly possess four kinds of contents; 3) approximately 70% of the organs are easy-to-transplant. Implementing our transplantation strategy for different kinds of organs, we manually extract 30 organs in three different programming languages, namely Java, Python, and C, and make unit tests for them utilizing four testing tools (two for Java, one for Python, and one for C). At last, we transplant three Java organs into a specific platform for a performance check to verify whether they can work well in the new system. All the 30 organs extracted by our strategy possess good performances in unit test with the highest passing rate reaching 97% and the lowest one still passing 80% and the three Java organs work well in the new system, providing three new functionalities for the host. All the results indicate the feasibility of organ transplantation based on open-source repository, bringing new idea for code reuse.
]]></description>
<dc:subject>software-engineering rather-odd not-a-bad-idea reuse crossover to-write-about</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:Vaguery/b:97d34ba55ec5/</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:rather-odd"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:not-a-bad-idea"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:reuse"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:crossover"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:to-write-about"/>
</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://arxiv.org/abs/1703.10862">
    <title>[1703.10862] Edit Transactions: Dynamically Scoped Change Sets for Controlled Updates in Live Programming</title>
    <dc:date>2017-04-25T10:47:53+00:00</dc:date>
    <link>https://arxiv.org/abs/1703.10862</link>
    <dc:creator>Vaguery</dc:creator><description><![CDATA[Live programming environments enable programmers to edit a running program and obtain immediate feedback on each individual change. The liveness quality is valued by programmers to help work in small steps and continuously add or correct small functionality while maintaining the impression of a direct connection between each edit and its manifestation at run-time. Such immediacy may conflict with the desire to perform a combined set of intermediate steps, such as a refactoring, without immediately taking effect after each individual edit. This becomes important when an incomplete sequence of small-scale changes can easily break the running program. State-of-the-art solutions focus on retroactive recovery mechanisms, such as debugging or version control. In contrast, we propose a proactive approach: Multiple individual changes to the program are collected in an Edit Transaction, which can be made effective if deemed complete. Upon activation, the combined steps become visible together. Edit Transactions are capable of dynamic scoping, allowing a set of changes to be tested in isolation before being extended to the running application. This enables a live programming workflow with full control over change granularity, immediate feedback on tests, delayed effect on the running application, and coarse-grained undos. We present an implementation of Edit Transactions along with Edit-Transaction-aware tools in Squeak/Smalltalk. We asses this implementation by conducting a case study with and without the new tool support, comparing programming activities, errors, and detours for implementing new functionality in a running simulation. We conclude that workflows using Edit Transactions have the potential to increase confidence in a change, reduce potential for run-time errors, and eventually make live programming more predictable and engaging.
]]></description>
<dc:subject>software-engineering programming dynamical-systems representation rather-interesting to-write-about consider:open-systems consider:simulations</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:Vaguery/b:7cb1fadfd586/</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:programming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:dynamical-systems"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:representation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:rather-interesting"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:to-write-about"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:consider:open-systems"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:consider:simulations"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://arxiv.org/abs/1502.03526">
    <title>[1502.03526] An Empirical Evaluation of Impact of Refactoring On Internal and External Measures of Code Quality</title>
    <dc:date>2015-03-15T12:43:28+00:00</dc:date>
    <link>http://arxiv.org/abs/1502.03526</link>
    <dc:creator>Vaguery</dc:creator><description><![CDATA[Refactoring is the process of improving the design of existing code by changing its internal structure without affecting its external behaviour, with the main aims of improving the quality of software product. Therefore, there is a belief that refactoring improves quality factors such as understandability, flexibility, and reusability. However, there is limited empirical evidence to support such assumptions. The objective of this study is to validate/invalidate the claims that refactoring improves software quality. The impact of selected refactoring techniques was assessed using both external and internal measures. Ten refactoring techniques were evaluated through experiments to assess external measures: Resource Utilization, Time Behaviour, Changeability and Analysability which are ISO external quality factors and five internal measures: Maintainability Index, Cyclomatic Complexity, Depth of Inheritance, Class Coupling and Lines of Code. The result of external measures did not show any improvements in code quality after the refactoring treatment. However, from internal measures, maintainability index indicated an improvement in code quality of refactored code than non-refactored code and other internal measures did not indicate any positive effect on refactored code
]]></description>
<dc:subject>refactoring software-engineering usability empirical-study rather-interesting performance-measure gotta-wonder</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:Vaguery/b:3514b8fdebaf/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:refactoring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:software-engineering"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:usability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:empirical-study"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:rather-interesting"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:performance-measure"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:gotta-wonder"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://arxiv.org/abs/1410.6449">
    <title>[1410.6449] Parallel Prefix Polymorphism Permits Parallelization, Presentation &amp; Proof</title>
    <dc:date>2014-11-29T13:12:03+00:00</dc:date>
    <link>http://arxiv.org/abs/1410.6449</link>
    <dc:creator>Vaguery</dc:creator><description><![CDATA[Polymorphism in programming languages enables code reuse. Here, we show that polymorphism has broad applicability far beyond computations for technical computing: parallelism in distributed computing, presentation of visualizations of runtime data flow, and proofs for formal verification of correctness. The ability to reuse a single codebase for all these purposes provides new ways to understand and verify parallel programs.
]]></description>
<dc:subject>parallel-processing concurrency languages computer-science verification rather-interesting software-engineering software-development-is-not-programming</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:Vaguery/b:c2b5fb204547/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:parallel-processing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:concurrency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:languages"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:computer-science"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:verification"/>
	<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:software-development-is-not-programming"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://arxiv.org/abs/1204.4224">
    <title>[1204.4224] Software Mutational Robustness</title>
    <dc:date>2012-12-31T13:16:56+00:00</dc:date>
    <link>http://arxiv.org/abs/1204.4224</link>
    <dc:creator>Vaguery</dc:creator><description><![CDATA[Neutral landscapes and mutational robustness are believed to be important enablers of evolvability in biology. We apply these concepts to software, defining mutational robustness to be the fraction of random mutations that leave a program's behavior unchanged. Test cases are used to measure program behavior and mutation operators are taken from genetic programming. Although software is often viewed as brittle, with small changes leading to catastrophic changes in behavior, our results show surprising robustness in the face of random software mutations. 

The paper describes empirical studies of the mutational robustness of 22 programs, including 14 production software projects, the Siemens benchmarks, and 4 specially constructed programs. We find that over 30% of random mutations are neutral with respect to their test suite. The results hold across all classes of programs, for mutations at both the source code and assembly instruction levels, across various programming languages, and are only weakly related to test suite coverage. We conclude that mutational robustness is an inherent property of software, and that neutral variants (i.e., those that pass the test suite) often fulfill the program's original purpose or specification. 

Based on these results, we conjecture that neutral mutations can be leveraged as a mechanism for generating software diversity. We demonstrate this idea by generating a population of neutral program variants and showing that the variants automatically repair unknown bugs with high probability. Neutral landscapes also provide a partial explanation for recent results that use evolutionary computation to automatically repair software bugs.
]]></description>
<dc:subject>evolutionary-algorithms software-development software-engineering robustness redundancy cultural-assumptions self-image-among-programmers</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:Vaguery/b:e9a1b6632f51/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:evolutionary-algorithms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:software-development"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:software-engineering"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:robustness"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:redundancy"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:cultural-assumptions"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:self-image-among-programmers"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://arxiv.org/abs/1205.5975">
    <title>[1205.5975] A Domain-Specific Compiler for Linear Algebra Operations</title>
    <dc:date>2012-06-08T15:15:10+00:00</dc:date>
    <link>http://arxiv.org/abs/1205.5975</link>
    <dc:creator>Vaguery</dc:creator><description><![CDATA["We present a prototypical linear algebra compiler that automatically exploits domain-specific knowledge to generate high-performance algorithms. The input to the compiler is a target equation together with knowledge of both the structure of the problem and the properties of the operands. The output is a variety of high-performance algorithms, and the corresponding source code, to solve the target equation. Our approach consists in the decomposition of the input equation into a sequence of library-supported kernels. Since in general such a decomposition is not unique, our compiler returns not one but a number of algorithms. The potential of the compiler is shown by means of its application to a challenging equation arising within the genome-wide association study. As a result, the compiler produces multiple "best" algorithms that outperform the best existing libraries."]]></description>
<dc:subject>domain-specific-language linear-algebra software-engineering compiler nudge-targets</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:Vaguery/b:1af4eb618e5e/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:domain-specific-language"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:linear-algebra"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:software-engineering"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:compiler"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:nudge-targets"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://engineering.twitter.com/2011/05/faster-ruby-kiji-update.html">
    <title>Twitter Engineering: Faster Ruby: Kiji Update</title>
    <dc:date>2011-05-28T12:09:12+00:00</dc:date>
    <link>http://engineering.twitter.com/2011/05/faster-ruby-kiji-update.html</link>
    <dc:creator>Vaguery</dc:creator><description><![CDATA["0.11 is a much more performant and operable runtime than Kiji 0.10. However, through this work we identified a practical strategy for making an even better, fully-generational version that would apply well to Ruby 1.9. Time will tell if we get to implement it."]]></description>
<dc:subject>Ruby software-engineering interpreter performance</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:Vaguery/b:22843f0185e8/</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:software-engineering"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:interpreter"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:performance"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www2.computer.org/cms/Computer.org/ComputingNow/homepage/2009/0709/rW_SO_Viewpoints.pdf">
    <title>Software Engineering [PDF]</title>
    <dc:date>2011-02-21T13:12:53+00:00</dc:date>
    <link>http://www2.computer.org/cms/Computer.org/ComputingNow/homepage/2009/0709/rW_SO_Viewpoints.pdf</link>
    <dc:creator>Vaguery</dc:creator><description><![CDATA["…In my reflective mood, I’m wonder- ing, was its advice correct at the time, is it still relevant, and do Istill believe that metrics are a must for any suc- cessful software development effort? My answers are no, no, and no."]]></description>
<dc:subject>software-engineering agility software-development metrics what-gets-measured-gets-fudged rescinded on-second-thought management-consulting</dc:subject>
<dc:identifier>https://pinboard.in/u:Vaguery/b:1274cf3b61ad/</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:agility"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:software-development"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:metrics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:what-gets-measured-gets-fudged"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:rescinded"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:on-second-thought"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:management-consulting"/>
</rdf:Bag></taxo:topics>
</item>
</rdf:RDF>