Search

Developers often need to use appropriate APIs to program efficiently, but it is usually a difficult task to identify the exact one they need from a vast of candidates. To ease the burden, a multitude of API recommendation approaches have been proposed. However, most of the currently available API recommenders do not support the effective integration of users' feedback into the recommendation loop. In this paper, we propose a framework, BRAID (Boosting RecommendAtion with Implicit FeeDback), which leverages learning-to-rank and active learning techniques to boost recommendation performance. By exploiting users' feedback information, we train a learning-to-rank model to re-rank the recommendation results. In addition, we speed up the feedback learning process with active learning. Existing query-based API recommendation approaches can be plugged into BRAID. We select three state-of-the-art API recommendation approaches as baselines to demonstrate the performance enhancement of BRAID measured by Hit@k (Top-k), MAP, and MRR. Empirical experiments show that, with acceptable overheads, the recommendation performance improves steadily and substantially with the increasing percentage of feedback data, comparing with the baselines., Comment: 15 pages, 4 figures

Test cases are crucial to help developers preventing the introduction of software faults. Unfortunately, not all the tests are properly designed or can effectively capture faults in production code. Some measures have been defined to assess test-case effectiveness: the most relevant one is the mutation score, which highlights the quality of a test by generating the so-called mutants , i.e., variations of the production code that make it faulty and that the test is supposed to identify. However, previous studies revealed that mutation analysis is extremely costly and hard to use in practice. The approaches proposed by researchers so far have not been able to provide practical gains in terms of mutation testing efficiency. This leaves the problem of efficiently assessing test-case effectiveness as still open. In this paper, we investigate a novel, orthogonal, and lightweight methodology to assess test-case effectiveness: in particular, we study the feasibility to exploit production and test-code-quality indicators to estimate the mutation score of a test case. We first select a set of 67 factors and study their relation with test-case effectiveness. Then, we devise a mutation score estimation model exploiting such factors and investigate its performance as well as its most relevant features. The key results of the study reveal that our estimation model only based on static features has 86 percent of both F-Measure and AUC-ROC. This means that we can estimate the test-case effectiveness, using source-code-quality indicators, with high accuracy and without executing the tests. As a consequence, we can provide a practical approach that is beyond the typical limitations of current mutation testing techniques.

More than two decades ago, researchers started to mine the data stored in software repositories to help software developers in making informed decisions for developing and testing software systems. Bug prediction was one of the most promising and popular research directions that uses the data stored in software repositories to predict the bug-proneness or number of bugs in source files. On that topic and as part of Emanuel's PhD studies, we submitted a paper with the title Comparing fine-grained source code changes and code churn for bug prediction [8] to the 8th Working Conference on Mining Software Engineering, held 2011 in beautiful Honolulu, Hawaii. Ten years later, it got selected as one of the finalists to receive the MSR 2021 Most Influential Paper Award. In the following, we provide a retrospective on our work, describing the road to publishing this paper, its impact in the field of bug prediction, and the road ahead.

Application Programming Interfaces (APIs) represent key tools for software developers to build complex software systems. However, several studies have revealed that even major API providers tend to have incomplete or inconsistent API documentation. This can severely hamper the API comprehension and, as a consequence, the quality of the software built on them. In this paper, we propose DRONE (Detect and Repair of dOcumentatioN dEfects), a framework to automatically detect and repair defects from API documents by leveraging techniques from program analysis, natural language processing, and constraint solving. Specifically, we target at the directives of API documents, which are related to parameter constraints and exception handling declarations. Furthermore, in presence of defects, we also provide a prototypical repair recommendation system. We evaluate our approach on parts of the well-documented APIs of JDK 1.8 APIs (including javaFX) and Android 7.0 (level 24). Across the two empirical studies, our approach can detect API defects with an average F-measure of 79.9, 71.7, and 81.4 percent, respectively. The API repairing capability has also been evaluated on the generated recommendations in a further experiment. User judgments indicate that the constraint information is addressed correctly and concisely in the rendered directives.

Ultrasound-guided core needle biopsy (CNB) is considered the standard assessment to diagnose sonographically visible suspicious breast mass lesions. Based on nonrandomized trials, the current German guidelines recommend at least three cylinders with ≤ 14-gauge needle biopsy. However, no recommendation is made as to how many specimens are needed with a smaller needle size, such as 16-gauge, or if biopsy with coaxial guidance improves diagnostic accuracy and quality. Therefore, in a prospective monocentric unblinded randomized controlled clinical noninferiority trial, the diagnostic accuracy of 16-gauge versus 14-gauge core needle biopsy, with and without coaxial guidance, was evaluated. 1065 breast biopsies were included in order to analyze the number of core samples necessary to obtain an appropriate rate of diagnostic quality adequate for histological evaluation, and to achieve high diagnostic accuracy and diagnostic yield. Histological results were verified by surgery or long-term follow-up of at least two years up to five years. In order to obtain an additive diagnostic accuracy of 99 %, a minimum of two cylinders with 14-gauge biopsy were required. The diagnostic accuracy and the diagnostic quality of 14-gauge biopsy were not affected by the coaxial technique. When performing a 16-gauge biopsy, five cylinders were required to achieve an additive diagnostic accuracy of 99 %. Without coaxial guidance, 16-gauge CNB required at least three samples, whereas five needle passes with coaxial-guided 16-gauge biopsy were needed. The diagnostic accuracy and quality of ultrasound-guided 16-gauge core needle biopsy were inferior to the 14-gauge needle size, regardless of the use of a coaxial technique.ZIEL: Die ultraschallgestützte Stanzbiopsie (CNB) gilt als Standardbewertung für die Diagnose sonografisch nachweisbarer verdächtiger Brustläsionen. Basierend auf nichtrandomisierten Studien empfehlen die aktuellen deutschen Richtlinien die Biopsie von mindestens 3 Zylindern mit ≤ 14-Gauche (G)-Nadel. Es wird jedoch keine Empfehlung abgegeben, wie viele Proben bei kleinerer Nadelstärke von z. B. 16-G benötigt werden, oder ob die koaxiale Führung die diagnostische Treffsicherheit und Qualität verbessert. Daher wurde in einer prospektiven, monozentrischen, nicht verblindeten, randomisierten, kontrollierten klinischen Nichtunterlegenheitsstudie die diagnostische Treffsicherheit der Stanzbiopsie mit 16-G-versus 14-G-Nadel mit und ohne Koaxialführung bewertet. 1065 Brustbiopsien wurden aufgenommen, um die Anzahl der erforderlichen Stanzproben zu analysieren, um eine entsprechende diagnostische Qualität zu erhalten, die für die histologische Beurteilung ausreicht und um eine hohe diagnostische Genauigkeit und Ausbeute zu erreichen. Die histologischen Ergebnisse wurden durch eine Operation oder eine Langzeitbeobachtung von mindestens 2 bis zu 5 Jahren bestätigt. Um eine additive diagnostische Genauigkeit von 99 % zu erreichen, waren mindestens 2 Zylinder mit 14-G-Biopsie erforderlich. Die diagnostische Genauigkeit und Qualität der 14-G-Biopsie wurden durch die koaxiale Technik nicht beeinträchtigt. Bei der Durchführung einer 16-G-Biopsie waren 5 Zylinder erforderlich, um eine additive diagnostische Genauigkeit von 99 % zu erreichen. Ohne koaxiale Führung benötigte die CNB mit 16-G mindestens 3 Proben, während 5 Nadelpassagen mit koaxialer 16-G-Biopsie erforderlich waren. Die diagnostische Treffsicherheit und Qualität der ultraschallgeführten Stanzbiopsie waren unabhängig vom Einsatz einer koaxialen Technik mit der 16-G-Nadel geringer als mit der 14-G-Nadel.

© 2020 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future media, including reprinting/republishing this material for advertising or promotional purposes, creating new collective works, for resale or redistribution to servers or lists, or reuse of any copyrighted component of this work in other works., In the current mobile app development, novel and emerging DevOps practices (e.g., Continuous Delivery, Integration, and user feedback analysis) and tools are becoming more widespread. For instance, the integration of user feedback (provided in the form of user reviews) in the software release cycle represents a valuable asset for the maintenance and evolution of mobile apps. To fully make use of these assets, it is highly desirable for developers to establish semantic links between the user reviews and the software artefacts to be changed (e.g., source code and documentation), and thus to localize the potential files to change for addressing the user feedback. In this paper, we propose RISING (Reviews Integration via claSsification, clusterIng, and linkiNG), an automated approach to support the continuous integration of user feedback via classification, clustering, and linking of user reviews. RISING leverages domain-specific constraint information and semi-supervised learning to group user reviews into multiple fine-grained clusters concerning similar users' requests. Then, by combining the textual information from both commit messages and source code, it automatically localizes potential change files to accommodate the users' requests. Our empirical studies demonstrate that the proposed approach outperforms the state-of-the-art baseline work in terms of clustering and localization accuracy, and thus produces more reliable results.

In Goal Recognition Design (GRD), the objective is to modify a domain to facilitate early detection of the goal of a subject agent. Most previous work studies this problem in the offline setting, in which the observing agent performs its interventions before the subject begins acting. In this paper, we generalize GRD to the online setting in which time passes and the observer's actions are interleaved with those of the subject. We illustrate weaknesses of existing metrics for GRD and propose an alternative better suited to online settings. We provide a formal definition of this Active GRD (AGRD) problem and study an algorithm for solving it. AGRD occupies an interesting middle ground between passive goal recognition and strategic two-player game settings.

Continuous integration is an agile software development practice. Instead of integrating features right before a release, they are constantly being integrated into an automated build process. This shortens the release cycle, improves software quality, and reduces time to market. However, the whole process will come to a halt when a commit breaks the build, which can happen for several reasons, e.g., compilation errors or test failures, and fixing the build suddenly becomes a top priority. Developers not only have to find the cause of the build break and fix it, but they have to be quick in all of it to avoid a delay for others. Unfortunately, these steps require deep knowledge and are often time-consuming. To support developers in fixing a build break, we propose Bart, a tool that summarizes the reasons for Maven build failures and suggests possible solutions found on the internet. We will show in a case study with 17 participants that developers find Bart useful to understand build breaks and that using Bart substantially reduces the time to fix a build break, on average by 37%. We have also conducted a qualitative study to better understand the workflows and information needs when fixing builds. We found that typical workflows differ substantially between various error categories, and that several uncommon build errors are both very hard to investigate and to fix. These findings will be useful to inform future research in this area.

Refactoring is a well-established practice that aims at improving the internal structure of a software system without changing its external behavior. Existing literature provides evidence of how and why developers perform refactoring in practice. In this paper, we continue on this line of research by performing a large-scale empirical analysis of refactoring practices in 200 open source systems. Specifically, we analyze the change history of these systems at commit level to investigate: (i) whether developers perform refactoring operations and, if so, which are more diffused and (ii) when refactoring operations are applied, and (iii) which are the main developer-oriented factors leading to refactoring. Based on our results, future research can focus on enabling automatic support for less frequent refactorings and on recommending refactorings based on the developer's workload, project's maturity and developer's commitment to the project.

Introduction: Currently, it is well known that quality assurance systems in healthcare organizations are constantly evolving. Quality improvements can reduce costs by avoiding repetition of exams, which results in a waste of time and money for the company, as well as customer and physician dissatisfaction. Objective: To quantify the cost that errors in the pre-analytical phase generate for the laboratory using the collection indicators, direct material cost, and operating cost. Materials and methods: The database of a large laboratory in the city of Porto Alegre, Rio Grande do Sul, was analyzed between January 2013 and July 2014. Results: A total cost of R$ 23,330.71 spent on recollections was obtained. Discussion: Management cost is committed to efficiency in reducing expenses, through studies and analyzes aimed at changing management and conduct processes. Conclusion: Cost management is necessary in any company because in the case where it fails to be carried out, besides the being able to bring the institution down to bankrupt, it brings negative costs, as well as impacts customers and physician’s satisfaction. RESUMEN Introducción: Actualmente, llama atención que los sistemas de garantía de calidad en organizaciones sanitarias están en constante evolución. Las mejoras en la calidad pueden reducir los costos, evitando la repetición de pruebas, que genera una pérdida de tiempo y dinero para la empresa, así como la insatisfacción de clientes y médicos. Objetivo: Cuantificar el costo que los errores en la fase preanalítica generan para el laboratorio, utilizando los indicadores de nueva extracción, el costo con material directo y el costo de operación. Materiales y métodos: Se analizó la base de datos de un gran laboratorio en la ciudad de Porto Alegre, Rio Grande do Sul, entre enero de 2013 y julio de 2014. Resultados: Obtuvimos un costo total de R$ 23.330,71 gastados en tomas repetidas. Discusión: El costo de gestión se compromete con la eficiencia en la reducción de gastos, mediante estudios y análisis orientados a cambiar los procesos de gestión y conducción. Conclusión: La gestión de costos es necesaria en cualquier empresa, porque si no se hace, además de poder llevar a la institución a la quiebra, trae costos negativos, así como impactos en la satisfacción de clientes y médicos. RESUMO Introdução: Atualmente, é notório que os sistemas de garantia da qualidade em organizações de assistência à saúde estão em constante evolução. As melhorias na qualidade podem reduzir os custos, evitando a repetição de exames, que gera desperdício de tempo e dinheiro para a empresa, bem como insatisfação do cliente e médico. Objetivo: Quantificar o custo que os erros na fase pré-analítica geram para o laboratório, utilizando os indicadores de recoleta, o custo com material direto e o custo de operação. Materiais e métodos: O banco de dados de um laboratório de grande porte da cidade de Porto Alegre, Rio Grande do Sul, foi analisado entre janeiro de 2013 e julho de 2014. Resultados: Obtivemos um total de R$ 23.330,71 gastos com as recoletas. Discussão: O custo gerencial compromete-se com a eficiência para redução dos gastos, por meio de estudos e análises voltados para mudanças de processos de administração e conduta. Conclusão: O gerenciamento de custo é necessário em qualquer empresa, pois, caso não seja realizado, além de poder levar a instituição à falência, traz custos negativos, assim como impactos na satisfação de clientes e médicos.

Executing software microbenchmarks, a form of small-scale performance tests predominantly used for libraries and frameworks, is a costly endeavor. Full benchmark suites take up to multiple hours or days to execute, rendering frequent checks, e.g., as part of continuous integration (CI), infeasible. However, altering benchmark configurations to reduce execution time without considering the impact on result quality can lead to benchmark results that are not representative of the software’s true performance. We propose the first technique to dynamically stop software microbenchmark executions when their results are sufficiently stable. Our approach implements three statistical stoppage criteria and is capable of reducing Java Microbenchmark Harness (JMH) suite execution times by 48.4% to 86.0%. At the same time it retains the same result quality for 78.8% to 87.6% of the benchmarks, compared to executing the suite for the default duration. The proposed approach does not require developers to manually craft custom benchmark configurations; instead, it provides automated mechanisms for dynamic reconfiguration. Hence, making dynamic reconfiguration highly effective and efficient, potentially paving the way to inclusion of JMH microbenchmarks in CI.

An effective and efficient application of Continuous Integration (CI) and Delivery (CD) requires software projects to follow certain principles and good practices. Configuring such a CI/CD pipeline is challenging and error-prone. Therefore, automated linters have been proposed to detect errors in the pipeline. While existing linters identify syntactic errors, detect security vulnerabilities or misuse of the features provided by build servers, they do not support developers that want to prevent common misconfigurations of a CD pipeline that potentially violate CD principles ("CD smells"). To this end, we propose CD-Linter, a semantic linter that can automatically identify four different smells in such a pipeline configuration file. We have evaluated our approach through a large-scale and long-term study that consists of (i) monitoring 145 issues (opened in as many open-source projects) over a period of 6 months, (ii) manually validating the detection precision and recall on a representative sample of issues, and (iii) assessing the magnitude of the observed smells on 5,312 open-source projects on GitLab. Our results show that CD smells are accepted and fixed by most of the developers and our linter achieves a precision of 87% and a recall of 94%. Those smells can be frequently observed in the wild, as 31% of projects with long configurations are affected by at least one smell. Data and Material, To appear in the proceedings of the ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering (ESEC/FSE), Sun 8 - Fri 13 November 2020 Sacramento, California, United States.

Source-code comments are an important communication medium between developers to better understand and maintain software. Current research focuses on auto-generating comments by summarizing the code. However, good comments contain additional details, like important design decisions or required trade-offs, and only developers can decide on the proper comment content. Automated summarization techniques cannot include information that does not exist in the code, therefore fully-automated approaches while helpful, will be of limited use. In our work, we propose to empower developers through a semi-automated system instead. We investigate the feasibility of using neural language models trained on a large corpus of Python documentation strings to generate completion suggestions and obtain promising results. By focusing on confident predictions, we can obtain a top-3 accuracy of over 70%, although this comes at the cost of lower suggestion frequency. Our models can be improved by leveraging context information like the signature and the full body of the method. Additionally, we are able to return good accuracy completions even for new projects, suggesting the generalizability of our approach.

Continuous Integration (CI) has been claimed to introduce several benefits in software development, including high software quality and reliability. However, recent work pointed out challenges, barriers and bad practices characterizing its adoption. This paper empirically investigates what are the bad practices experienced by developers applying CI. The investigation has been conducted by leveraging semi-structured interviews of 13 experts and mining more than 2,300 Stack Overflow posts. As a result, we compiled a catalog of 79 CI bad smells belonging to 7 categories related to different dimensions of a CI pipeline management and process. We have also investigated the perceived importance of the identified bad smells through a survey involving 26 professional developers, and discussed how the results of our study relate to existing knowledge about CI bad practices. Whilst some results, such as the poor usage of branches, confirm existing literature, the study also highlights uncovered bad practices, e.g., related to static analysis tools or the abuse of shell scripts, and contradict knowledge from existing literature, e.g., about avoiding nightly builds. We discuss the implications of our catalog of CI bad smells for (i) practitioners, e.g., favor specific, portable tools over hacking, and do not ignore nor hide build failures, (ii) educators, e.g., teach CI culture, not just technology, and teach CI by providing examples of what not to do, and (iii) researchers, e.g., developing support for failure analysis, as well as automated CI bad smell detectors.

Context Continuous experimentation guides development activities based on data collected on a subset of online users on a new experimental version of the software. It includes practices such as canary releases, gradual rollouts, dark launches, or A/B testing. Objective Unfortunately, our knowledge of continuous experimentation is currently primarily based on well-known and outspoken industrial leaders. To assess the actual state of practice in continuous experimentation, we conducted a mixed-method empirical study. Method In our empirical study consisting of four steps, we interviewed 31 developers or release engineers, and performed a survey that attracted 187 complete responses. We analyzed the resulting data using statistical analysis and open coding. Results Our results lead to several conclusions: (1) from a software architecture perspective, continuous experimentation is especially enabled by architectures that foster independently deployable services, such as microservices-based architectures; (2) from a developer perspective, experiments require extensive monitoring and analytics to discover runtime problems, consequently leading to developer on call policies and influencing the role and skill sets required by developers; and (3) from a process perspective, many organizations conduct experiments based on intuition rather than clear guidelines and robust statistics. Conclusion Our findings show that more principled and structured approaches for release decision making are needed, striving for highly automated, systematic, and data- and hypothesis-driven deployment and experimentation.

Ein regelmasiges Crew-Resource-Management (CRM)-basiertes Simulationstraining verandert moglicherweise die Sicherheitskultur einer Organisation. Im Jahr 2012 wurde an der Anasthesiologischen Klinik ein jahrliches Simulationstraining etabliert. Anhand von Dimensionen des Safety Attitudes Questionnaire (SAQ) sollte die Frage beantwortet werden, ob sich bei wiederholter Teilnahme an einem Simulationstraining sicherheitsrelevante Einstellungen von Teilnehmenden verandern. Es wurden 3 Dimensionen des SAQ (Teamarbeitsklima, Sicherheitsklima, Stresswahrnehmung) sowie eigene Frageitems zu Vorbesprechungen (Briefings) und zum „speaking up“ verwendet. Vor Beginn jedes Simulatorkurses wurden die Teilnehmenden gebeten, den Fragebogen auszufullen. Anhand eines personalisierten Codes konnten bei wiederholter Teilnahme Daten anonym Individuen zugeordnet werden. Zur Auswertung wurde die Funfpunkte-Likert-Skala in eine 100-Punkte-Skala transformiert. Die mittlere Veranderung pro Jahr wurde mit einem univariablen linearen Regressionsmodell berechnet. Die Antworten von 255 Personen wurden erfasst. Jedes Jahr nahmen ≤20 % der pflegerischen und ≤90 % der moglichen arztlichen Belegschaft teil. Der jahrliche Anteil an neuen Mitarbeitern betrug 16–24 %. Anhand eines personalisierten Codes konnte ein Vorher-nachher-Vergleich mit 99 Personen erfolgen, die 2‑mal und haufiger teilgenommen hatten. Vor Beginn des ersten Trainings schatzten Arzte die Teamarbeit besser ein als Pflegekrafte (+8,7; p < 0,001). Die Einschatzung vor Beginn des ersten Simulationstrainings stieg im Beobachtungszeitraum leicht an: Sie betrug pro Jahr 3,11 fur das Teamarbeitsklima (p < 0,001) und 2,73 fur das Sicherheitsklima (p = 0,001). Bei mehrfacher Teilnahme war die Veranderung bei Pflegekraften etwas starker ausgepragt (Teamarbeitsklima 5,2 (Pflege) vs. 1,4 (Arzte); Sicherheitsklima 5,3 (Pflege) vs. 2,8 (Arzte)) ohne Signifikanz zu erreichen. Ein jahrliches CRM-basiertes Simulationstraining kann beim Teamarbeitsklima und Sicherheitsklima eine geringe Veranderung uber die Zeit bewirken. Eine geringe Teilnahme an Pflegekraften und eine hohe Personalfluktuation schwachen moglicherweise die Auswirkungen des Trainings auf das Sicherheitsklima ab.

Understanding the evolution of a project is crucial in reverse-engineering, auditing and otherwise understanding existing software. Visualizing how software evolves can be challenging, as it typically abstracts a multi-dimensional graph structure where individual components undergo frequent but localized changes. Existing approaches typically consider either only a small number of revisions or they focus on one particular aspect, such as the evolution of code metrics or architecture. Approaches using a static view with a time axis (such as line charts) are limited in their expressiveness regarding structure, and approaches visualizing structure quickly become cluttered with an increasing number of revisions and components. We propose a novel trade-off between displaying global structure over a large time period with reduced accuracy and visualizing fine-grained changes of individual components with absolute accuracy. We demonstrate how our approach displays changes by blending redundant visual features (such as scales or repeating data points) where they are not expressive. We show how using this approach to explore software evolution can reveal ephemeral information when familiarizing oneself with a new project. We provide a working implementation as an extension to our open-source library for fine-grained evolution analysis, LISA.

Recent advances in machine learning have stimulated widespread interest within the Information Technology sector on integrating AI capabilities into software and services. This goal has forced organizations to evolve their development processes. We report on a study that we conducted on observing software teams at Microsoft as they develop AI-based applications. We consider a nine-stage workflow process informed by prior experiences developing AI applications (e.g., search and NLP) and data science tools (e.g. application diagnostics and bug reporting). We found that various Microsoft teams have united this workflow into preexisting, well-evolved, Agile-like software engineering processes, providing insights about several essential engineering challenges that organizations may face in creating large-scale AI solutions for the marketplace. We collected some best practices from Microsoft teams to address these challenges. In addition, we have identified three aspects of the AI domain that make it fundamentally different from prior software application domains: 1) discovering, managing, and versioning the data needed for machine learning applications is much more complex and difficult than other types of software engineering, 2) model customization and model reuse require very different skills than are typically found in software teams, and 3) AI components are more difficult to handle as distinct modules than traditional software components --- models may be "entangled" in complex ways and experience non-monotonic error behavior. We believe that the lessons learned by Microsoft teams will be valuable to other organizations.

Code completion is commonly used by software developers and is integrated into all major IDE's. Good completion tools can not only save time and effort but may also help avoid incorrect API usage. Many proposed completion tools have shown promising results on synthetic benchmarks, but these benchmarks make no claims about the realism of the completions they test. This lack of grounding in real-world data could hinder our scientific understanding of developer needs and of the efficacy of completion models. This paper presents a case study on 15,000 code completions that were applied by 66 real developers, which we study and contrast with artificial completions to inform future research and tools in this area. We find that synthetic benchmarks misrepresent many aspects of real-world completions; tested completion tools were far less accurate on real-world data. Worse, on the few completions that consumed most of the developers' time, prediction accuracy was less than 20% -- an effect that is invisible in synthetic benchmarks. Our findings have ramifications for future benchmarks, tool design and real-world efficacy: Benchmarks must account for completions that developers use most, such as intra-project APIs; models should be designed to be amenable to intra-project data; and real-world developer trials are essential to quantifying performance on the least predictable completions, which are both most time-consuming and far more typical than artificial data suggests. We publicly release our preprint [https://doi.org/10.5281/zenodo.2565673] and replication data and materials [https://doi.org/10.5281/zenodo.2562249].

Good unit tests play a paramount role when it comes to foster and evaluate software quality. However, writing effective tests is an extremely costly and time consuming practice. To reduce such a burden for developers, researchers devised ingenious techniques to automatically generate test suite for existing code bases. Nevertheless, how automatically generated test cases fare against manually written ones is an open research question. In 2008, Bacchelli et al. conducted an initial case study comparing automatic and manually generated test suites. Since in the last ten years we have witnessed a huge amount of work on novel approaches and tools for automatic test generation, in this paper we revise their study using current tools as well as complementing their research method by evaluating these tools' ability in finding regressions., Preprint of the publication appeared in the proceedings of the 16th International Conference on Mining Software Repositories (MSR 2019), Montréal, Canada, 2019.

© 2019 IEEE. Because of differences between development and production environments, many software performance problems are detected only after software enters production. We present PerformanceHat, a new system that uses profiling information from production executions to develop a global performance model suitable for integration into interactive development environments. PerformanceHat's ability to incrementally update this global model as the software is changed in the development environment enables it to deliver near real-time predictions of performance consequences reflecting the impact on the production environment. We implement PerformanceHat as an Eclipse plugin and evaluate it in a controlled experiment with 20 professional software developers implementing several software maintenance tasks using our approach and a representative baseline (Kibana). Our results indicate that developers using PerformanceHat were significantly faster in (1) detecting the performance problem, and (2) finding the root-cause of the problem. These results provide encouraging evidence that our approach helps developers detect, prevent, and debug production performance problems during development before the problem manifests in production.

Continuous Integration (CI) is a widely-used software engineering practice. The software is continuously built so that changes can be easily integrated and issues such as unmet quality goals or style inconsistencies get detected early. Unfortunately, it is not only hard to introduce CI into an existing project, but it is also challenging to live up to the CI principles when facing tough deadlines or business decisions. Previous work has identified common anti-patterns that reduce the promised benefits of CI. Typically, these anti-patterns slowly creep into a project over time before they are identified. We argue that automated detection can help with early identification and prevent such a process decay. In this work, we further analyze this assumption and survey 124 developers about CI anti-patterns. From the results, we build CI-Odor, a reporting tool for CI processes that detects the existence of four relevant anti-patterns by analyzing regular build logs and repository information. In a study on the 18,474 build logs of 36 popular Java projects, we reveal the presence of 3,823 high-severity warnings spread across projects. We validate our reports in a survey among 13 original developers of these projects and through general feedback from 42 developers that confirm the relevance of our reports., To appear in the proceedings of the 41st IEEE/ACM International Conference on Software Engineering (ICSE) technical track, Montréal, Canada, 2019.

Researchers often analyze several revisions of a software project to obtain historical data about its evolution. For example, they statically analyze the source code and monitor the evolution of certain metrics over multiple revisions. The time and resource requirements for running these analyses often make it necessary to limit the number of analyzed revisions, e.g., by only selecting major revisions or by using a coarse-grained sampling strategy, which could remove significant details of the evolution. Most existing analysis techniques are not designed for the analysis of multi-revision artifacts and they treat each revision individually. However, the actual difference between two subsequent revisions is typically very small. Thus, tools tailored for the analysis of multiple revisions should only analyze these differences, thereby preventing re-computation and storage of redundant data, improving scalability and enabling the study of a larger number of revisions. In this work, we propose the Lean Language-Independent Software Analyzer (LISA), a generic framework for representing and analyzing multi-revisioned software artifacts. It employs a redundancy-free, multi-revision representation for artifacts and avoids re-computation by only analyzing changed artifact fragments across thousands of revisions. The evaluation of our approach consists of measuring the effect of each individual technique incorporated, an in-depth study of LISA resource requirements and a large-scale analysis over 7 million program revisions of 4,000 software projects written in four languages. We show that the time and space requirements for multi-revision analyses can be reduced by multiple orders of magnitude, when compared to traditional, sequential approaches.

© 2019 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future media, including reprinting/republishing this material for advertising or promotional purposes, creating new collective works, for resale or redistribution to servers or lists, or reuse of any copyrighted component of this work in other works., Communication means, such as issue trackers, mailing lists, Q&A forums, and app reviews, are premier means of collaboration among developers, and between developers and end-users. Analyzing such sources of information is crucial to build recommenders for developers, for example suggesting experts, re-documenting source code, or transforming user feedback in maintenance and evolution strategies for developers. To ease this analysis, in previous work we proposed DECA (Development Emails Content Analyzer), a tool based on Natural Language Parsing that classifies with high precision development emails' fragments according to their purpose. However, DECA has to be trained through a manual tagging of relevant patterns, which is often effort-intensive, error-prone and requires specific expertise in natural language parsing. In this paper, we first show, with a study involving Master's and Ph.D. students, the extent to which producing rules for identifying such patterns requires effort, depending on the nature and complexity of patterns. Then, we propose an approach, named NEON (Nlp-based softwarE dOcumentation aNalyzer), that automatically mines such rules, minimizing the manual effort. We assess the performances of NEON in the analysis and classification of mobile app reviews, developers discussions, and issues. NEON simplifies the patterns' identification and rules' definition processes, allowing a savings of more than 70% of the time otherwise spent on performing such activities manually. Results also show that NEON-generated rules are close to the manually identified ones, achieving comparable recall.

Software testing represents a key software engineering practice to ensure source code quality and reliability. To support developers in this activity and reduce testing effort, several automated unit test generation tools have been proposed. Most of these approaches have the main goal of covering as more branches as possible. While these approaches have good performance, little is still known on the maintainability of the test code they produce, i.e.,whether the generated tests have a good code quality and if they do not possibly introduce issues threatening their effectiveness. To bridge this gap, in this paper we study to what extent existing automated test case generation tools produce potentially problematic test code. We consider seven test smells, i.e.,suboptimal design choices applied by programmers during the development of test cases, as measure of code quality of the generated tests, and evaluate their diffuseness in the unit test classes automatically generated by three state-of-the-art tools such as Randoop , JTExpert , and Evosuite . Moreover, we investigate whether there are characteristics of test and production code influencing the generation of smelly tests. Our study shows that all the considered tools tend to generate a high quantity of two specific test smell types, i.e.,Assertion Roulette and Eager Test, which are those that previous studies showed to negatively impact the reliability of production code. We also discover that test size is correlated with the generation of smelly tests. Based on our findings, we argue that more effective automated generation algorithms that explicitly take into account test code quality should be further investigated and devised.

Q methodology provides a novel, quantitative approach to reveal stakeholder perspectives and was used to assess social acceptance of Marine Protected Areas (MPAs) with fisheries and conservation management goals using the Devon & Severn region, UK as a case study site. Participants sorted a set of statements ( n =42) into a forced-choice frequency distribution and centroid analysis revealed three factors for interpretation: (1) ‘pro-conservation’, characterised by views that conservation should be prioritised over commercial and economic interests; (2) ‘pro-fisheries’ who saw fishing as the priority and expressed concerns over the uncertainty of management measures and the number of planned MPAs; and (3) ‘win–win’ who felt that the current approach to marine management using MPAs would allow both fisheries and conservation goals to be met. Despite some differences in opinion, social acceptability of MPAs was identified across all three discourses, but was limited by the knock-on effects of the exclusion of stakeholders from the implementation of MPAs and the development of management measures. This resulted in disenfranchisement and uncertainty over the future of their activities. The results suggest that social acceptability of MPAs is generated by effective and ongoing stakeholder engagement, transparency and honesty relating to the costs and benefits of designations and a certainty that once sites are in place the resources exist for their effective management. Understanding social acceptability will guide adaptive management and increase the chances of MPA success and the meeting of global targets.

Bug reports represent an important information source for software construction. Misclassification of these reports inevitably introduces bias. Manual examinations can help reduce the noise, but bring a heavy burden for developers instead. In this paper, we propose a multi-stage approach by combining both text mining and data mining techniques to automate the prediction process. The first stage leverages text mining techniques to analyze the summary parts of bug reports and classifies them into three levels of probability. The extracted features and some other structured features of bug reports are then fed into the machine learner in the second stage. Data grafting techniques are employed to bridge the two stages. Comparative experiments with previous studies on the same data-three large-scale open-source projects-consistently achieve a reasonable enhancement from 77.4% to 81.7%, 76.1% to 81.6%, and 87.4% to 93.7%, respectively over their best results in terms of overall performance. Additional comparative empirical experiments on other seven popular open-source systems confirm the findings. Moreover, based on the data obtained, we also empirically studied the impact relation between the underlying classifiers and various other properties of the combined model. A prototypical recommender system has been developed to demonstrate the applicability of our approach. Copyright © 2016 John Wiley & Sons, Ltd.

Marine Protected Areas (MPAs) are an important tool for the maintenance of marine ecosystem functionality and health and ensuring the onward flow of beneficial ecosystem services that support human well-being. Social and economic factors influence whether and how stakeholders exploit resources or cooperate to conserve them. Environmental managers are now turning from designating MPAs to monitoring their effectiveness. Combining spatial analysis with quantitative and qualitative survey methods this research shows that an MPA (Lyme Bay, SW England) has had varying effects on the delivery of the beneficial ecosystem service of leisure and recreation. In the survey years 2008–2011 dive businesses have increased their frequency of activity inside and outside the MPA and report an increase in turnover; though they perceive little or no effect of the MPA on business. Charter boat operators have seen an overall decline in the frequency of activity outside the MPA and an increase inside the MPA. They perceive that the MPA has increasingly had a positive effect on their business. Sea angling activity has declined at sites outside the MPA and increased at sites within the MPA, suggesting a redistribution of spatial activity. Diving activity has increased both inside and outside the MPA. Divers report that the MPA has influenced where they choose to dive. This corresponds to a potential increase in value of the MPA resource (represented as the proportional expenditure and associated turnover by these groups) of £2.2 million. This research demonstrates that the use of the resource has changed following designation and that MPAs can attract a greater proportion of the leisure and recreation expenditure and associated turnover to sites within the MPA boundary. Moving forward it is important to assess effects both inside and outside MPAs. Integrating high quality social science at MPA sites to track effectiveness can help to adapt and refine management strategies to reflect the needs of the stakeholders and support effective conservation.

Developers discuss software architecture and concrete source code implementations on a regular basis, be it on question-answering sites, online chats, mailing lists or face to face. In many cases, there is more than one way of solving a programming task. Which way is best may be decided based on case-specific circumstances and constraints, but also based on convention. Having strong conventions, and a common vocabulary to express them, simplifies communication and strengthens common understanding of software development problems and their solutions. While many programming ecosystems have a common vocabulary, Python’s relationship to conventions and common language is a particularly pronounced. The “Zen of Python”, a famous set of high-level coding conventions authored by Tim Peters, states “There should be one, and preferably only one, obvious way to do it”. This ‘one way to do it’ is often referred to as the ‘Pythonic’ way: the ideal solution to a particular problem. Few other programming languages have coined a unique term to label the quality of craftsmanship gone into a software artifact. In this paper, we explore how Python developers understand the term ‘Pythonic’ by means of structured interviews, build a catalogue of ‘pythonic idioms’ gathered from literature, and conjecture on the effects of having a language-specific term for quality code, considering the potential it could hold for other programming languages and ecosystems. We find that while the term means different things to novice versus experienced Python developers, it encompasses not only concrete implementation, but a way of thinking - a culture - in general.

Automatically generating test cases plays an important role to reduce the time spent by developers during the testing phase. In last years, several approaches have been proposed to tackle such a problem: amongst the others, search-based techniques have been shown to be particularly promising. In this paper we describe Ocelot, a search-based tool for the automatic generation of test cases in C. Ocelot allows practitioners to write skeletons of test cases for their programs and researchers to easily implement and experiment new approaches for automatic test-data generation. We show that Ocelot achieves a higher coverage compared to a competitive tool in 81% of the cases. Ocelot is publicly available to support both researchers and practitioners.

By definition, the practice of Continuous Integration (CI) promotes continuous software quality improvement. In systems adopting such a practice, quality assurance is usually performed by using static and dynamic analysis tools (e.g., SonarQube) that compute overall metrics such as maintainability or reliability measures. Furthermore, developers usually define quality gates, i.e., source code quality thresholds that must be reached by the software product after every newly committed change. If certain quality gates fail (e.g., a maintainability metric is below a settled threshold), developers should refactor the code possibly addressing some of the proposed warnings. While previous research findings showed that refactoring is often not done in practice, it is still unclear whether and how the adoption of a CI philosophy has changed the way developers perceive and adopt refactoring. In this paper, we preliminarily study—running a survey study that involves 31 developers—how developers perform refactoring in CI, which needs they have and the barriers they face while continuously refactor source code.

Continuous Integration (CI) is a software engineering practice where developers constantly integrate their changes to a project through an automated build process. The goal of CI is to provide developers with prompt feedback on several quality dimensions after each change. Indeed, previous studies provided empirical evidence on a positive association between properly following CI principles and source code quality. A core principle behind CI is Continuous Code Quality (also known as CCQ, which includes automated testing and automated code inspection) may appear simple and effective, yet we know little about its practical adoption. In this paper, we propose a preliminary empirical investigation aimed at understanding how rigorously practitioners follow CCQ. Our study reveals a strong dichotomy between theory and practice: developers do not perform continuous inspection but rather control for quality only at the end of a sprint and most of the times only on the release branch., To appear in the proceedings of the 33rd IEEE/ACM International Conference on Automated Software Engineering (ASE), Montpellier, France, 2018.

It is crucial for a software manager to know whether or not one can rely on a bug prediction model. A wrong prediction of the number or the location of future bugs can lead to problems in the achievement of a project's goals. In this paper we first verify the existence of variability in a bug prediction model's accuracy over time both visually and statistically. Furthermore, we explore the reasons for such a high variability over time, which includes periods of stability and variability of prediction quality, and formulate a decision procedure for evaluating prediction models before applying them. To exemplify our findings we use data from four open source projects and empirically identify various project features that influence the defect prediction quality. Specifically, we observed that a change in the number of authors editing a file and the number of defects fixed by them influence the prediction quality. Finally, we introduce an approach to estimate the accuracy of prediction models that helps a project manager decide when to rely on a prediction model. Our findings suggest that one should be aware of the periods of stability and variability of prediction quality and should use approaches such as ours to assess their models' accuracy in advance.

Continuous integration is an agile software development practice. Instead of integrating features right before a release, they are constantly being integrated in an automated build process. This shortens the release cycle, improves software quality, and reduces time to market. However, the whole process will come to a halt when a commit breaks the build, which can happen for several reasons, e.g., compilation errors or test failures, and fixing the build suddenly becomes a top priority. Developers not only have to find the cause of the build break and fix it, but they have to be quick in all of it to avoid a delay for others. Unfortunately, these steps require deep knowledge and are often time consuming. To support developers in fixing a build break, we propose Bart, a tool that summarizes the reasons of the build failure and suggests possible solutions found on the Internet. We will show in a case study with eight participants that developers find Bart useful to understand build breaks and that using Bart substantially reduces the time to fix a build break, on average by 41%.

Performance problems observed in production environments that have their origin in program code are immensely hard to localize and prevent. Data that can help solve such problems is usually found in external dashboards and is thus not integrated into the software development process. We propose an approach that augments source code with runtime traces to tightly integrate runtime performance traces into developer workflows. Our goal is to create operational awareness of performance problems in developers' code and contextualize this information to tasks they are currently working on. We implemented this approach as an Eclipse IDE plugin for Java applications that is available as an open source project on GitHub. A video of PerformanceHat in action is online: https://youtu.be/fTBBiylRhag

Group-living animals need to trade off the benefits and the costs of close proximity to conspecifics. Benefits can be increased, and costs reduced by preferentially choosing specific locations within a group best adjusted to an individual’s needs or by associating with specific group members and/or avoiding others. We investigated the spatial structure of meerkat (Suricata suricatta) groups and whether it was shaped by social factors such as affiliation or aggression among group members, predation risk, foraging success, or a mix of these different factors. Using social network analyses, based on spatial networks, we found associations between the dominant pair, among males and among same aged individuals, and dis-assortment by sex only in one to two of the six groups. In addition, the structure of meerkat groups was highly variable, as individual strength within the calculated networks was not repeatable over time. Meerkats seemed to adjust their location to their physical environment, as dominant individuals were located further toward the front of the group, where foraging success is likely higher and young individuals located further toward the back of the group, where they can benefit most from the vigilance effort of their conspecifics. We conclude that meerkat groups display a dynamic spatial structure depending on both the current social and physical environmental. Group-living animals can achieve greater benefits from close association with conspecifics by choosing specific locations within a group or associating with specific group members and/or avoiding others. A considerable body of work has examined how differences in predation risk or foraging success affect the relative location of individuals within a group. Several studies investigated the association between individuals, in order to draw conclusions on the social structure. However, it is important to disentangle the impact of all of these different aspects on the spatial structure of a group. Here, we provide evidence that both the social and physical environment is important for the spatial assortment of meerkats, a social mongoose foraging in cohesive groups.

Software testing is a crucial component in modern continuous integration development environment. Ideally, at every commit, all the system's test cases should be executed and moreover, new test cases should be generated for the new code. This is especially true in a Continuous Test Generation (CTG) environment, where the automatic generation of test cases is integrated into the continuous integration pipeline. Furthermore, developers want to achieve a minimum level of coverage for every build of their systems. Since both executing all the test cases and generating new ones for all the classes at every commit is not feasible, they have to select which subset of classes has to be tested. In this context, knowing a priori the branch coverage that can be achieved with test data generation tools might give some useful indications for answering such a question. In this paper, we take the first steps towards the definition of machine learning models to predict the branch coverage achieved by test data generation tools. We conduct a preliminary study considering well known code metrics as a features. Despite the simplicity of these features, our results show that using machine learning to predict branch coverage in automated testing is a viable and feasible option.

Software testing is one of the most crucial tasks in the typical development process. Developers are usually required to write unit test cases for the code they implement. Since this is a time-consuming task, in last years many approaches and tools for automatic test case generation --- such as EvoSuite--- have been introduced. Nevertheless, developers have to maintain and evolve tests to sustain the changes in the source code; therefore, having readable test cases is important to ease such a process. However, it is still not clear whether developers make an effort in writing readable unit tests. Therefore, in this paper, we conduct an explorative study comparing the readability of manually written test cases with the classes they test. Moreover, we deepen such analysis looking at the readability of automatically generated test cases. Our results suggest that developers tend to neglect the readability of test cases and that automatically generated test cases are generally even less readable than manually written ones.

Today’s software development is all about data: data about the software product itself, about the process and its different stages, about the customers and markets, about the development, the testing, the integration, the deployment, or the runtime aspects in the cloud. We use static and dynamic data of various kinds and quantities to analyze market feedback, feature impact, code quality, architectural design alternatives, or effects of performance optimizations. Development environments are no longer limited to IDEs in a desktop application or the like but span the Internet using live programming environments such as Cloud9 or large-volume repositories such as BitBucket, GitHub, GitLab, or StackOverflow. Software development has become “live” in the cloud, be it the coding, the testing, or the experimentation with different product options on the Internet. The inherent complexity puts a further burden on developers, since they need to stay alert when constantly switching between tasks in different phases. Research has been analyzing the development process, its data and stakeholders, for decades and is working on various tools that can help developers in their daily tasks to improve the quality of their work and their productivity. In this chapter, we critically reflect on the challenges faced by developers in a typical release cycle, identify inherent problems of the individual phases, and present the current state of the research that can help overcome these issues.

ContextContinuous Integration (CI) has become an established best practice of modern software development. Its philosophy of regularly integrating the changes of individual developers with the master code base saves the entire development team from descending into Integration Hell, a term coined in the field of extreme programming. In practice, CI is supported by automated tools to cope with this repeated integration of source code through automated builds and testing. One of the main problems, however, is that relevant information about the quality and health of a software system is both scattered across those tools and across multiple views. ObjectiveThis paper introduces a quality awareness framework for CI-data and its conceptional model used for the data integration and visualization. The framework called SQA-Mashup makes use of the service-based mashup paradigm and integrates information from the entire CI-toolchain into a single service. MethodThe research approach followed in our work consists out of (i) a conceptional model for data integration and visualization, (ii) a prototypical framework implementation based on tool requirements derived from literature, and (iii) a controlled user study to evaluate its usefulness. ResultsThe results of the controlled user study showed that SQA-Mashup's single point of access allows users to answer questions regarding the state of a system more quickly (57%) and accurately (21.6%) than with standalone CI-tools. ConclusionsThe SQA-Mashup framework can serve as one-stop shop for software quality data monitoring in a software development project. It enables easy access to CI-data which otherwise is not integrated but scattered across multiple CI-tools. Our dynamic visualization approach allows for a tailoring of integrated CI-data according to information needs of different stakeholders such as developers or testers.

Researchers have proposed several approaches to extract information from user reviews useful for maintaining and evolving mobile apps. However, most of them just perform automatic classification of user reviews according to specific keywords (e.g., bugs, features). Moreover, they do not provide any support for linking user feedback to the source code components to be changed, thus requiring a manual, time-consuming, and error-prone task. In this paper, we introduce ChangeAdvisor, a novel approach that analyzes the structure, semantics, and sentiments of sentences contained in user reviews to extract useful (user) feedback from maintenance perspectives and recommend to developers changes to software artifacts. It relies on natural language processing and clustering algorithms to group user reviews around similar user needs and suggestions for change. Then, it involves textual based heuristics to determine the code artifacts that need to be maintained according to the recommended software changes. The quantitative and qualitative studies carried out on 44 683 user reviews of 10 open source mobile apps and their original developers showed a high accuracy of ChangeAdvisor in (i) clustering similar user change requests and (ii) identifying the code components impacted by the suggested changes. Moreover, the obtained results show that ChangeAdvisor is more accurate than a baseline approach for linking user feedback clusters to the source code in terms of both precision (+47%) and recall (+38%).

Diagnosing problems in large-scale, distributed applications running in cloud environments requires investigating different sources of information to reason about application state at any given time. Typical sources of information available to developers and operators include log statements and other runtime information collected by monitors, such as application and system metrics. Just as importantly, developers rely on information related to changes to the source code and configuration files (program code) when troubleshooting. This information is generally scattered, and it is up to the troubleshooter to inspect multiple implicitly-connected fragments thereof. Currently, different tools need to be used in conjunction, e.g., log aggregation tools, source- code management tools, and runtime-metric dashboards, each requiring different data sources and workflows. Not surprisingly, diagnosing problems is a difficult proposition. In this paper, we propose Context-Based Analytics, an approach that makes the links between runtime information and program-code fragments explicit by constructing a graph based on an application-context model. Implicit connections between information fragments are explicitly represented as edges in the graph. We designed a framework for expressing application-context models and implemented a prototype. Further, we instantiated our prototype framework with an application-context model for two real cloud applications, one from IBM and another from a major telecommunications provider. We applied context-based analytics to diagnose two issues taken from the issue tracker of the IBM application and found that our approach reduced the effort of diagnosing these issues. In particular, context-based analytics decreased the number of required analysis steps by 48% and the number of needed inspected traces by 40% on average as compared to a standard diagnosis approach.

Application Programming Interface (API) documents represent one of the most important references for API users. However, it is frequently reported that the documentation is inconsistent with the source code and deviates from the API itself. Such inconsistencies in the documents inevitably confuse the API users hampering considerably their API comprehension and the quality of software built from such APIs. In this paper, we propose an automated approach to detect defects of API documents by leveraging techniques from program comprehension and natural language processing. Particularly, we focus on the directives of the API documents which are related to parameter constraints and exception throwing declarations. A first-order logic based constraint solver is employed to detect such defects based on the obtained analysis results. We evaluate our approach on parts of well documented JDK 1.8 APIs. Experiment results show that, out of around 2000 API usage constraints, our approach can detect 1158 defective document directives, with a precision rate of 81.6%, and a recall rate of 82.0%, which demonstrates its practical feasibility.

More than other machine learning techniques, neural networks have been shown to excel at tasks where humans traditionally outperform computers: recognizing objects in images, distinguishing spoken words from background noise or playing "Go". These are hard problems, where hand-crafting solutions is rarely feasible due to their inherent complexity. Higher level program comprehension is not dissimilar in nature: while a compiler or program analysis tool can extract certain facts from (correctly written) code, it has no intrinsic 'understanding' of the data and for the majority of real-world problems, a human developer is needed - for example to find and fix a bug or to summarize the bahavior of a method. We perform a pilot study to determine the suitability of neural machine translation (NMT) for processing plain-text source code. We find that, on one hand, NMT is too fragile to accurately tokenize code, while on the other hand, it can precisely recognize different types of tokens and make accurate guesses regarding their relative position in the local syntax tree. Our results suggest that NMT may be exploited for annotating and enriching out-of-context code snippets to support automated tooling for code comprehension problems. We also identify several challenges in applying neural networks to learning from source code and determine key differences between the application of existing neural network models to source code instead of natural language.

Docker allows packaging an application with its dependencies into a standardized, self-contained unit (a so-called container), which can be used for software development and to run the application on any system. Dockerfiles are declarative definitions of an environment that aim to enable reproducible builds of the container. They can often be found in source code repositories and enable the hosted software to come to life in its execution environment. We conduct an exploratory empirical study with the goal of characterizing the Docker ecosystem, prevalent quality issues, and the evolution of Dockerfiles. We base our study on a data set of over 70000 Dockerfiles, and contrast this general population with samplings that contain the Top-100 and Top-1000 most popular Docker-using projects. We find that most quality issues (28.6%) arise from missing version pinning (i.e., specifying a concrete version for dependencies). Further, we were not able to build 34% of Dockerfiles from a representative sample of 560 projects. Integrating quality checks, e.g., to issue version pinning warnings, into the container build process could result into more reproducible builds. The most popular projects change more often than the rest of the Docker population, with 5.81 revisions per year and 5 lines of code changed on average. Most changes deal with dependencies, that are currently stored in a rather unstructured manner. We propose to introduce an abstraction that, for instance, could deal with the intricacies of different package managers and could improve migration to more light-weight images.

The mobile applications industry experiences an unprecedented high growth, developers working in this context face a fierce competition in acquiring and retaining users. They have to quickly implement new features and fix bugs, or risks losing their users to the competition. To achieve this goal they must closely monitor and analyze the user feedback they receive in form of reviews. However, successful apps can receive up to several thousands of reviews per day, manually analysing each of them is a time consuming task. To help developers deal with the large amount of available data, we manually analyzed the text of 1566 user reviews and defined a high and low level taxonomy containing mobile specific categories (e.g. performance, resources, battery, memory, etc.) highly relevant for developers during the planning of maintenance and evolution activities. Then we built the User Request Referencer (URR) prototype, using Machine Learning and Information Retrieval techniques, to automatically classify reviews according to our taxonomy and recommend for a particular review what are the source code files that need to be modified to handle the issue described in the user review. We evaluated our approach through an empirical study involving the reviews and code of 39 mobile applications. Our results show a high precision and recall of URR in organising reviews according to the defined taxonomy.

Group coordination, when ‘on the move’ or when visibility is low, is a challenge faced by many social living animals. While some animals manage to maintain cohesion solely through visual contact, the mechanism of group cohesion through other modes of communication, a necessity when visual contact is reduced, is not yet understood. Meerkats ( Suricata suricatta ), a small, social carnivore, forage as a cohesive group while moving continuously. While foraging, they frequently emit ‘close calls’, soft close-range contact calls. Variations in their call rates based on their local environment, coupled with individual movement, produce a dynamic acoustic landscape with a moving ‘vocal hotspot’ of the highest calling activity. We investigated whether meerkats follow such a vocal hotspot by playing back close calls of multiple individuals to foraging meerkats from the front and back edge of the group simultaneously. These two artificially induced vocal hotspots caused the group to spatially elongate and split into two subgroups. We conclude that meerkats use the emergent dynamic call pattern of the group to adjust their movement direction and maintain cohesion. Our study describes a highly flexible mechanism for the maintenance of group cohesion through vocal communication, for mobile species in habitats with low visibility and where movement decisions need to be adjusted continuously to changing environmental conditions.