Short Introduction to This Paper

This paper investigates the concept of a "program repair bot" and present Repairnator. The Repairnator bot is an autonomous agent that constantly monitors test failures, reproduces bugs, and runs program repair tools against each reproduced bug. If a patch is found, Repairnator bot reports it to the developers. At the time of writing, Repairnator uses three different program repair systems and has been operating since February 2017. In total, it has studied 11 317 test failures over 1 609 open-source software projects hosted on GitHub, and has generated patches for 17 different bugs.

Highlights of This Paper

• A blueprint design of a program repair bot for continuous integration (CI) test failures
• A set of unique empirical facts about program repair and bug reproduction collected over 11 317 test failures across 1 609 software projects
• 7 recommendations to help future authors of program repair bots

- Read the full article -

Short Introduction to This Paper

This paper gives us an introduction about how Etsy uses "GameDay" to build more confidence about their system's behavior. Specifically, it includes the discussion about 1) why apply it in production environment, 2) how to do fault injection during a GameDay exercise, 3) business justification and 4) a case, limitations and fear.

Highlights of This Paper

• Introduction about the provisioning of a server or cloud instance from zero to production
• Explanation about why many complex systems are largely intractable
• Pattern about GameDay exercise, introducing the methodology of how they doing fault injection in a real company

- Read the full article -

Short Introduction to This Paper

This paper deeply studied 395 patches of the Defects4J dataset. Quantitative properties (patch size and spreading) were automatically extracted, whereas qualitative ones (repair actions and patterns) were manually extracted using a thematic analysisbased approach. It found that:

1) the median size of Defects4J patches is four lines, and almost 30% of the patches contain only addition of lines;
2) 92% of the patches change only one file, and 38% has no spreading at all;
3) the top-3 most applied repair actions are addition of method calls, conditionals, and assignments, occurring in 77% of the patches;
4) nine repair patterns were found for 95% of the patches, where the most prevalent, appearing in 43% of the patches, is on conditional blocks.

These results are useful for researchers to perform advanced analysis on their techniques’ results based on Defects4J. Moreover, this set of properties can be used to characterize and compare different bug datasets

Highlights of This Paper

• The anatomy of the patches in Defects4J containing an extensive set of patch properties, consolidated into a JSON file and augmented with a web user-interface to facilitate exploration
• A bug dataset dissection methodology to extract valuable quantitative and qualitative properties regarding patches from bug datasets. The methodology is based on diff and advanced patch analysis and combines automated and manual thematic analysis
• A taxonomy of repair actions and patterns, resulted from manual analysis of patches according our methodology

Key Infomation

• Research questions:

  • What is the size distribution of Defects4J patches?
  • To what extent are Defects4J patches spread in source code?
  • What is the composition of Defects4J patches in terms of repair actions (additions, removals and modifications) over code elements (e.g. conditions and method calls)?
  • What repair patterns can be found in Defects4J using a manual thematic analysis?
• Data Collection: For each bug, first produced diff views between the buggy program version and its associated fixed version. These views served as source for data extraction and analysis

• Repair Patterns in the Defects4J Patches:

  • Conditional Block
  • Expression Fix
  • Wraps-with / Unwraps-from
  • Single Line
  • Wrong Reference
  • Missing Null-Check
  • Copy / Paste
  • Constant Change
  • Code Moving

Relevant Future Works

• Maybe some supplement for Defects4J's document
• Characterization and comparison between different bug datasets

URL

Dissection of a Bug Dataset: Anatomy of 395 Patches from Defects4J

Part I Intruduction

Chaos Engineering is the discipline of experimenting on a distributed system in order to build confidence in the system’s capability to withstand turbulent conditions in production.
-- Principles of Chaos

Using Chaos Engineering may be as simple as manually running kill -9 on a box inside of your staging environment to simulate failure of a service. Or, it can be as sophisticated as automatically designing and carrying out experiments in a production enviroment against a small but statistically significant fraction of live traffic.

The History of Chaos Engineering at Netflix: started in 2008

• Chaos Monkey: ball rolling, gaining notoriety for turning off services in the production environment
• Chaos Kong: transferred those benefits from the small scale to the very large
• Failure Injection Testing (FIT): the foundation for tackling the space in between

- Read the full article -

Short Introduction to This Paper

This paper introduces and explores the idea of data poisoning, a light-weight peer-architecture technique to inject faults into Python programs. This method requires very small modification to the original program, which facilitates evaluation of sensitivity of systems that are prototyped or modeled in Python. Actually this paper doesn't show much detail about the implementation, but the types of data poisoning it declares are very interesting.

Highlights of This Paper

• Data poisoning's symbolic expression
• Different types of data poisoning

Key Infomation

• Types of data poisoning: deterministic effect poisoning, intermittent effect poisoning (need define the lifetime of poisoned data), infectious/non-infectious poisoning

Relevant Future Works

• Only doing data poisoning is not enough, we should analysis the system's behaviour under different types of perturbation

URL

Data Poisoning: Lightweight Soft Fault Injection for Python