Concepts

• Robustness, flexibility and resilience

Continuous Testing

• In-production Continuous Testing For Future Telco Cloud

Self-healing Software

• Characterizing self-healing software systems
• Elements of the self-healing system problem space

Exception Handling

• A lightweight approach to component-level exception mechanism for robust android apps
• An Exception Monitoring System for Java

Useful For Experiments

• XCorpus An executable Corpus of Java Programs
• SMARTLOG: Place Error Log Statement by Deep Understanding of Log Intention
• LinkedOut: A Request-Level Failure Injection Framework

Skills

• How to write a good abstract? An answer by Philip Koopman, Carnegie Mellon University

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

Background

This post introduces 2 basic solutions about docker monitoring. And what's more, we want to dig into metrics exporting methods. In order to do some data analysis, we want to extract metrics in a usable/simple format (e.g. CSV). It's easy to query some metrics, but the tools paid less attention to export multiple metrics joined by timestamp(this can be some scenarios about data analysis, or dev daily report), we are going to build a small tools for this.

- Read the full article -