This document summarizes the results of a large-scale empirical study on the relationship between build systems and build maintenance activity. The study analyzed over 800,000 open source projects to compare how different build technologies (e.g. Make, Autotools, Maven) affect build churn, source code coupling, and authorship over time. The key findings are that framework-based build systems tend to have higher build churn, tighter source code coupling, and decreasing authorship as projects migrate to more advanced technologies.
Tracing Software Build Processes to Uncover License Compliance InconsistenciesShane McIntosh
Open Source Software (OSS) components form the basis for many software systems. While the use of OSS components accelerates development, client systems must comply with the license terms of the OSS components that they use. Failure to do so exposes client system distributors to possible litigation from copyright holders. Yet despite the importance of license compliance, tool support for license compliance assessment is lacking. In this paper, we propose an approach to extract and analyze the Concrete Build Dependency Graph (CBDG) of a software system by tracing system calls that occur at build-time. Through a case study of seven open source systems, we show that the extracted CBDGs: (1) accurately classify sources as included in or excluded from deliverables with 88%-100% precision and 98%-100% recall, and (2) can uncover license compliance inconsistencies in real software systems - two of which prompted code fixes in the CUPS and FFmpeg systems.
Mining Co-Change Information to Understand when Build Changes are NecessaryShane McIntosh
As a software project ages, its source code is modified to add new features, restructure existing ones, and fix defects. These source code changes often induce changes in the build system, i.e., the system that specifies how source code is translated into deliverables. However, since developers are often not familiar with the complex and occasionally archaic technologies used to specify build systems, they may not be able to identify when their source code changes require accompanying build system changes. This can cause build breakages that slow development progress and impact other developers, testers, or even users. In this paper, we mine the source and test code changes that required accompanying build changes in order to better understand this co-change relationship. We build random forest classifiers using language-agnostic and language-specific code change characteristics to explain when code-accompanying build changes are necessary based on historical trends. Case studies of the Mozilla C++ system, the Lucene and Eclipse open source Java systems, and the IBM Jazz proprietary Java system indicate that our classifiers can accurately explain when build co-changes are necessary with an AUC of 0.60-0.88. Unsurprisingly, our highly accurate C++ classifiers (AUC of 0.88) derive much of their explanatory power from indicators of structural change (e.g., was a new source file added?). On the other hand, our Java classifiers are less accurate (AUC of 0.60-0.78) because roughly 75% of Java build co-changes do not coincide with changes to the structure of a system, but rather are instigated by concerns related to release engineering, quality assurance, and general build maintenance.
Identifying Hotspots in the PostgreSQL Build ProcessShane McIntosh
Software developers rely on a fast and correct build system to compile their source code changes and produce modified deliverables for testing and deployment. The scale and complexity of the PostgreSQL build process makes build performance an important topic to discuss and address.
In this talk, we will introduce a new build performance analysis technique that identifies "build hotspots", i.e., files that are slow to rebuild (by analyzing a build dependency graph), yet change often (by analyzing version control history). We will discuss the identified hotspots in the 9.2.4 release of PostgreSQL.
Build systems orchestrate how human-readable source code is translated into executable programs. In a software project, source code changes can induce changes in the build system (aka. build co-changes). It is difficult for developers to identify when build co-changes are necessary due to the complexity of build systems. Prediction of build co-changes works well if there is a sufficient amount of training data to build a model. However, in practice, for new projects, there exists a limited number of changes. Using training data from other projects to predict the build co-changes in a new project can help improve the performance of the build co-change prediction. We refer to this problem as cross-project build co-change prediction.
In this paper, we propose CroBuild, a novel cross-project build co-change prediction approach that iteratively learns new classifiers. CroBuild constructs an ensemble of classifiers by iteratively building classifiers and assigning them weights according to its prediction error rate. Given that only a small proportion of code changes are build co-changing, we also propose an imbalance-aware approach that learns a threshold boundary between those code changes that are build co-changing and those that are not in order to construct classifiers in each iteration. To examine the benefits of CroBuild, we perform experiments on 4 large datasets including Mozilla, Eclipse-core, Lucene, and Jazz, comprising a total of 50,884 changes. On average, across the 4 datasets, CroBuild achieves a F1-score of up to 0.408. We also compare CroBuild with other approaches such as a basic model, AdaBoost proposed by Freund et al., and TrAdaBoost proposed by Dai et al.. On average, across the 4 datasets, the CroBuild approach yields an improvement in F1-scores of 41.54%, 36.63%, and 36.97% over the basic model, AdaBoost, and TrAdaBoost, respectively.
The Impact of Code Review Coverage and Participation on Software QualityShane McIntosh
Software code review, i.e., the practice of having third-party team members critique changes to a software system, is a well-established best practice in both open source and proprietary software domains. Prior work has shown that the formal code inspections of the past tend to improve the quality of software delivered by students and small teams. However, the formal code inspection process mandates strict review criteria (e.g., in-person meetings and reviewer checklists) to ensure a base level of review quality, while the modern, lightweight code reviewing process does not. Although recent work explores the modern code review process qualitatively, little research quantitatively explores the relationship between properties of the modern code review process and software quality. Hence, in this paper, we study the relationship between software quality and: (1) code review coverage, i.e., the proportion of changes that have been code reviewed, and (2) code review participation, i.e., the degree of reviewer involvement in the code review process. Through a case study of the Qt, VTK, and ITK projects, we find that both code review coverage and participation share a significant link with software quality. Low code review coverage and participation are estimated to produce components with up to two and five additional post-release defects respectively. Our results empirically confirm the intuition that poorly reviewed code has a negative impact on software quality in large systems using modern reviewing tools.
Tracing Software Build Processes to Uncover License Compliance InconsistenciesShane McIntosh
Open Source Software (OSS) components form the basis for many software systems. While the use of OSS components accelerates development, client systems must comply with the license terms of the OSS components that they use. Failure to do so exposes client system distributors to possible litigation from copyright holders. Yet despite the importance of license compliance, tool support for license compliance assessment is lacking. In this paper, we propose an approach to extract and analyze the Concrete Build Dependency Graph (CBDG) of a software system by tracing system calls that occur at build-time. Through a case study of seven open source systems, we show that the extracted CBDGs: (1) accurately classify sources as included in or excluded from deliverables with 88%-100% precision and 98%-100% recall, and (2) can uncover license compliance inconsistencies in real software systems - two of which prompted code fixes in the CUPS and FFmpeg systems.
Mining Co-Change Information to Understand when Build Changes are NecessaryShane McIntosh
As a software project ages, its source code is modified to add new features, restructure existing ones, and fix defects. These source code changes often induce changes in the build system, i.e., the system that specifies how source code is translated into deliverables. However, since developers are often not familiar with the complex and occasionally archaic technologies used to specify build systems, they may not be able to identify when their source code changes require accompanying build system changes. This can cause build breakages that slow development progress and impact other developers, testers, or even users. In this paper, we mine the source and test code changes that required accompanying build changes in order to better understand this co-change relationship. We build random forest classifiers using language-agnostic and language-specific code change characteristics to explain when code-accompanying build changes are necessary based on historical trends. Case studies of the Mozilla C++ system, the Lucene and Eclipse open source Java systems, and the IBM Jazz proprietary Java system indicate that our classifiers can accurately explain when build co-changes are necessary with an AUC of 0.60-0.88. Unsurprisingly, our highly accurate C++ classifiers (AUC of 0.88) derive much of their explanatory power from indicators of structural change (e.g., was a new source file added?). On the other hand, our Java classifiers are less accurate (AUC of 0.60-0.78) because roughly 75% of Java build co-changes do not coincide with changes to the structure of a system, but rather are instigated by concerns related to release engineering, quality assurance, and general build maintenance.
Identifying Hotspots in the PostgreSQL Build ProcessShane McIntosh
Software developers rely on a fast and correct build system to compile their source code changes and produce modified deliverables for testing and deployment. The scale and complexity of the PostgreSQL build process makes build performance an important topic to discuss and address.
In this talk, we will introduce a new build performance analysis technique that identifies "build hotspots", i.e., files that are slow to rebuild (by analyzing a build dependency graph), yet change often (by analyzing version control history). We will discuss the identified hotspots in the 9.2.4 release of PostgreSQL.
Build systems orchestrate how human-readable source code is translated into executable programs. In a software project, source code changes can induce changes in the build system (aka. build co-changes). It is difficult for developers to identify when build co-changes are necessary due to the complexity of build systems. Prediction of build co-changes works well if there is a sufficient amount of training data to build a model. However, in practice, for new projects, there exists a limited number of changes. Using training data from other projects to predict the build co-changes in a new project can help improve the performance of the build co-change prediction. We refer to this problem as cross-project build co-change prediction.
In this paper, we propose CroBuild, a novel cross-project build co-change prediction approach that iteratively learns new classifiers. CroBuild constructs an ensemble of classifiers by iteratively building classifiers and assigning them weights according to its prediction error rate. Given that only a small proportion of code changes are build co-changing, we also propose an imbalance-aware approach that learns a threshold boundary between those code changes that are build co-changing and those that are not in order to construct classifiers in each iteration. To examine the benefits of CroBuild, we perform experiments on 4 large datasets including Mozilla, Eclipse-core, Lucene, and Jazz, comprising a total of 50,884 changes. On average, across the 4 datasets, CroBuild achieves a F1-score of up to 0.408. We also compare CroBuild with other approaches such as a basic model, AdaBoost proposed by Freund et al., and TrAdaBoost proposed by Dai et al.. On average, across the 4 datasets, the CroBuild approach yields an improvement in F1-scores of 41.54%, 36.63%, and 36.97% over the basic model, AdaBoost, and TrAdaBoost, respectively.
The Impact of Code Review Coverage and Participation on Software QualityShane McIntosh
Software code review, i.e., the practice of having third-party team members critique changes to a software system, is a well-established best practice in both open source and proprietary software domains. Prior work has shown that the formal code inspections of the past tend to improve the quality of software delivered by students and small teams. However, the formal code inspection process mandates strict review criteria (e.g., in-person meetings and reviewer checklists) to ensure a base level of review quality, while the modern, lightweight code reviewing process does not. Although recent work explores the modern code review process qualitatively, little research quantitatively explores the relationship between properties of the modern code review process and software quality. Hence, in this paper, we study the relationship between software quality and: (1) code review coverage, i.e., the proportion of changes that have been code reviewed, and (2) code review participation, i.e., the degree of reviewer involvement in the code review process. Through a case study of the Qt, VTK, and ITK projects, we find that both code review coverage and participation share a significant link with software quality. Low code review coverage and participation are estimated to produce components with up to two and five additional post-release defects respectively. Our results empirically confirm the intuition that poorly reviewed code has a negative impact on software quality in large systems using modern reviewing tools.
Collecting and Leveraging a Benchmark of Build System Clones to Aid in Qualit...Shane McIntosh
Build systems specify how sources are transformed into deliverables, and hence must be carefully maintained to ensure that deliverables are assembled correctly. Similar to source code, build systems tend to grow in complexity unless specifications are refactored. This paper describes how clone detection can aid in quality assessments that determine if and where build refactoring effort should be applied. We gauge cloning rates in build systems by collecting and analyzing a benchmark comprising 3,872 build systems. Analysis of the benchmark reveals that: (1) build systems tend to have higher cloning rates than other software artifacts, (2) recent build technologies tend to be more prone to cloning, especially of configuration details like API dependencies, than older technologies, and (3) build systems that have fewer clones achieve higher levels of reuse via mechanisms not offered by build technologies. Our findings aided in refactoring a large industrial build system containing 1.1 million lines.
The Bash Dashboard (Or: How to Use Bash for Data Analysis)Bram Adams
Tutorial on how to use basic Bash concepts and commands to analyze CSV files. It uses a real-life data set and structures the content along concrete analysis questions. Feel free to contact me with questions or suggestions!
Becoming A Plumber: Building Deployment Pipelines - LISA17Daniel Barker
A core part of our IT transformation program is the implementation of deployment pipelines for every application. Attendees will learn how to build abstract pipelines that will allow multiple types of applications to fit the same basic pipeline structure. This has been a big win for injecting change and updating legacy applications.
Git is a compelling version control system, but it is useful to talk about it in the context of a destination, made possible by migration tools from previous version control systems like Subversion. This talk offers a set of motivations, tools, and techniques on the Subversion to Git and GitHub migration process.
Delivered on April 21, 2012
.Net Hijacking to Defend PowerShell BSidesSF2017 Amanda Rousseau
With the rise of attacks implementing PowerShell in the recent months, there hasn’t been a solid solution for monitoring or prevention. Currently Microsoft released the AMSI solution for PowerShell v5 however this can also be bypassed. This talk will focus on utilizing various stealthy runtime .NET hijacking techniques implemented for blue teamer defenses for PowerShell attacks. The paper will start with a light intro into .NET and PowerShell, then a deeper explanation of various attacker techniques which will be explained in the perspective of the blue teamer. Techniques include assembly modification, class and method injection, compiler profiling, and C based function hooking.
Becoming a Plumber: Building Deployment Pipelines - All Day DevOpsDaniel Barker
A core part of our IT transformation program is the implementation of deployment pipelines for every application. Attendees will learn how to build abstract pipelines that will allow multiple types of applications to fit the same basic pipeline structure. This has been a big win for injecting change and updating legacy applications.
Git is a version control system. We can look at it from that high level. Git is a content tracking system. Some teachers advise us to look at it from that lowered elevation. But I will take you to the very bottom. The floor. The code. The algorithms. The directed acyclic graph of hashed bit sequences made efficient through LZW compression and deferred garbage collection determined by node reachability via hash relationships.
“But why?”, you may ask. “Why go this deep?”" Git is a tool that works so well for so many. It mystically corrects anticipated `merge` conflicts. It’s “where did code come from” results from `blame` are impressive. The ability to re-write history through `rebase` is awesome. The globally unique identifier nature of a hash-produced ref is revolutionary.
Uber-geeks are magic-slayers. We want and need to know precisely how things work. Like a hard 50 push-up workout, this study will make working with Git at the daily developer level a fraction of the effort — like a mere ten push-ups. Join Matthew McCullough of GitHub and let’s dig into the guts of Git.
Delivered on June 17, 2012
Matthew McCullough of GitHub presented on why Java developers have so many reasons to explore Git and Git, including productivity gains, easy OSS contributions, the eGit Eclipse plugin, and JGit, the underlying Java cleanroom implementation that powers https://android.googlesource.com.
Delivered on June 9, 2012
BenchFlow: A Platform for End-to-end Automation of Performance Testing and An...Vincenzo Ferme
BenchFlow is an open-source expert system providing a complete platform for automating performance tests and performance analysis. We know that not all the developers are performance experts, but in nowadays agile environment, they need to deal with performance testing and performance analysis every day. In BenchFlow, the users define objective-driven performance testing using an expressive and SUT-aware DSL implemented in YAML. Then BenchFlow automates the end-to-end process of executing the performance tests and providing performance insights, dealing with system under test deployment relying on Docker technologies, distributing simulated users load on different server, error handling, performance data collection and performance metrics and insights computation.
My talk for SPEC Research Group DevOps (https://research.spec.org/devopswg) about BenchFlow. Discover BenchFlow: https://github.com/benchflow
In this presentation, I covered how I've migrated Android project from old Jenkins (Freestyle jobs, 1st Jenkins instance) to new Jenkins (Multibranch pipeline, 2nd Jenkins instance).
Also, it covers a Jenkins Shared Library usage and integration tests on pipeline code.
At the end, I'm covering pros/cons of final result and what difficulties I faced during migration.
Docker on a local machine and Docker in production — are two big differences. It's easy to play with technology but it's hard to do something real for many customers.
Half a year ago inside of AlfaLab (division of Alfa-Bank) we've started building architecture with microservices approach for few our pilot projects. We've almost completely changed a stack of the used technologies on a frontend and significantly changed it on a middle layer. For package and distribution we have choosen Docker. Two months ago we've deployed project to production and have opened service for clients.
In the report the following topics will be covered:
- reasons of a choice Docker;
- why Docker without other tools is not enough for a production;
- what stack of technologies we used in our solution;
- what advantages we've got;
- what problems have been faced and how we've solved them.
Improving code quality with continuous integration (PHPBenelux Conference 2011)Martin de Keijzer
Continuous Integration is the combination of any number of the available tools used to improve quality of both code and process. In this session we will look at these available tools and how these can be used. We will also look at Continuous Integration in general and CruiseControl in particular, at how to set it up and built a platform for robust and high-quality code. This session is a must-see for development leaders and technical managers alike, to understand the available options and the advantages offered by this approach.
Docker on a local machine and Docker in production — are two big differences. It's easy to play with technology but it's hard to do something real for many customers.
Half a year ago inside of Alpha Laboratory (division of Alfa-Bank) we've started building new microservices architecture for one of our pilot projects. We've almost completely changed a stack of the used technologies on a frontend and significantly changed it on a middle layer. For package and distribution we have choosen Docker. Two months ago we've deployed project to production and have opened service for clients.
In the report the following topics will be covered:
- reasons of a choice Docker;
- why Docker without other tools is not enough for a production;
- what stack of technologies we used in our solution;
- what advantages we've got;
- what problems have been faced and how we've solved them.
Collecting and Leveraging a Benchmark of Build System Clones to Aid in Qualit...Shane McIntosh
Build systems specify how sources are transformed into deliverables, and hence must be carefully maintained to ensure that deliverables are assembled correctly. Similar to source code, build systems tend to grow in complexity unless specifications are refactored. This paper describes how clone detection can aid in quality assessments that determine if and where build refactoring effort should be applied. We gauge cloning rates in build systems by collecting and analyzing a benchmark comprising 3,872 build systems. Analysis of the benchmark reveals that: (1) build systems tend to have higher cloning rates than other software artifacts, (2) recent build technologies tend to be more prone to cloning, especially of configuration details like API dependencies, than older technologies, and (3) build systems that have fewer clones achieve higher levels of reuse via mechanisms not offered by build technologies. Our findings aided in refactoring a large industrial build system containing 1.1 million lines.
The Bash Dashboard (Or: How to Use Bash for Data Analysis)Bram Adams
Tutorial on how to use basic Bash concepts and commands to analyze CSV files. It uses a real-life data set and structures the content along concrete analysis questions. Feel free to contact me with questions or suggestions!
Becoming A Plumber: Building Deployment Pipelines - LISA17Daniel Barker
A core part of our IT transformation program is the implementation of deployment pipelines for every application. Attendees will learn how to build abstract pipelines that will allow multiple types of applications to fit the same basic pipeline structure. This has been a big win for injecting change and updating legacy applications.
Git is a compelling version control system, but it is useful to talk about it in the context of a destination, made possible by migration tools from previous version control systems like Subversion. This talk offers a set of motivations, tools, and techniques on the Subversion to Git and GitHub migration process.
Delivered on April 21, 2012
.Net Hijacking to Defend PowerShell BSidesSF2017 Amanda Rousseau
With the rise of attacks implementing PowerShell in the recent months, there hasn’t been a solid solution for monitoring or prevention. Currently Microsoft released the AMSI solution for PowerShell v5 however this can also be bypassed. This talk will focus on utilizing various stealthy runtime .NET hijacking techniques implemented for blue teamer defenses for PowerShell attacks. The paper will start with a light intro into .NET and PowerShell, then a deeper explanation of various attacker techniques which will be explained in the perspective of the blue teamer. Techniques include assembly modification, class and method injection, compiler profiling, and C based function hooking.
Becoming a Plumber: Building Deployment Pipelines - All Day DevOpsDaniel Barker
A core part of our IT transformation program is the implementation of deployment pipelines for every application. Attendees will learn how to build abstract pipelines that will allow multiple types of applications to fit the same basic pipeline structure. This has been a big win for injecting change and updating legacy applications.
Git is a version control system. We can look at it from that high level. Git is a content tracking system. Some teachers advise us to look at it from that lowered elevation. But I will take you to the very bottom. The floor. The code. The algorithms. The directed acyclic graph of hashed bit sequences made efficient through LZW compression and deferred garbage collection determined by node reachability via hash relationships.
“But why?”, you may ask. “Why go this deep?”" Git is a tool that works so well for so many. It mystically corrects anticipated `merge` conflicts. It’s “where did code come from” results from `blame` are impressive. The ability to re-write history through `rebase` is awesome. The globally unique identifier nature of a hash-produced ref is revolutionary.
Uber-geeks are magic-slayers. We want and need to know precisely how things work. Like a hard 50 push-up workout, this study will make working with Git at the daily developer level a fraction of the effort — like a mere ten push-ups. Join Matthew McCullough of GitHub and let’s dig into the guts of Git.
Delivered on June 17, 2012
Matthew McCullough of GitHub presented on why Java developers have so many reasons to explore Git and Git, including productivity gains, easy OSS contributions, the eGit Eclipse plugin, and JGit, the underlying Java cleanroom implementation that powers https://android.googlesource.com.
Delivered on June 9, 2012
BenchFlow: A Platform for End-to-end Automation of Performance Testing and An...Vincenzo Ferme
BenchFlow is an open-source expert system providing a complete platform for automating performance tests and performance analysis. We know that not all the developers are performance experts, but in nowadays agile environment, they need to deal with performance testing and performance analysis every day. In BenchFlow, the users define objective-driven performance testing using an expressive and SUT-aware DSL implemented in YAML. Then BenchFlow automates the end-to-end process of executing the performance tests and providing performance insights, dealing with system under test deployment relying on Docker technologies, distributing simulated users load on different server, error handling, performance data collection and performance metrics and insights computation.
My talk for SPEC Research Group DevOps (https://research.spec.org/devopswg) about BenchFlow. Discover BenchFlow: https://github.com/benchflow
In this presentation, I covered how I've migrated Android project from old Jenkins (Freestyle jobs, 1st Jenkins instance) to new Jenkins (Multibranch pipeline, 2nd Jenkins instance).
Also, it covers a Jenkins Shared Library usage and integration tests on pipeline code.
At the end, I'm covering pros/cons of final result and what difficulties I faced during migration.
Docker on a local machine and Docker in production — are two big differences. It's easy to play with technology but it's hard to do something real for many customers.
Half a year ago inside of AlfaLab (division of Alfa-Bank) we've started building architecture with microservices approach for few our pilot projects. We've almost completely changed a stack of the used technologies on a frontend and significantly changed it on a middle layer. For package and distribution we have choosen Docker. Two months ago we've deployed project to production and have opened service for clients.
In the report the following topics will be covered:
- reasons of a choice Docker;
- why Docker without other tools is not enough for a production;
- what stack of technologies we used in our solution;
- what advantages we've got;
- what problems have been faced and how we've solved them.
Improving code quality with continuous integration (PHPBenelux Conference 2011)Martin de Keijzer
Continuous Integration is the combination of any number of the available tools used to improve quality of both code and process. In this session we will look at these available tools and how these can be used. We will also look at Continuous Integration in general and CruiseControl in particular, at how to set it up and built a platform for robust and high-quality code. This session is a must-see for development leaders and technical managers alike, to understand the available options and the advantages offered by this approach.
Docker on a local machine and Docker in production — are two big differences. It's easy to play with technology but it's hard to do something real for many customers.
Half a year ago inside of Alpha Laboratory (division of Alfa-Bank) we've started building new microservices architecture for one of our pilot projects. We've almost completely changed a stack of the used technologies on a frontend and significantly changed it on a middle layer. For package and distribution we have choosen Docker. Two months ago we've deployed project to production and have opened service for clients.
In the report the following topics will be covered:
- reasons of a choice Docker;
- why Docker without other tools is not enough for a production;
- what stack of technologies we used in our solution;
- what advantages we've got;
- what problems have been faced and how we've solved them.
Orchestrating Change: An Artistic Representation of Software EvolutionShane McIntosh
Several visualization tools have been proposed to highlight interesting software evolution phenomena. These tools help practitioners to navigate large and complex software systems, and also support researchers in studying software evolution. However, little work has explored the use of sound in the context of software evolution. In this paper, we propose the use of musical interpretation to support exploration of software evolution data. In order to generate music inspired by software evolution, we use parameter-based sonification, i.e., a mapping of dataset characteristics to sound. Our approach yields musical scores that can be played synthetically or by a symphony orchestra. In designing our approach, we address three challenges: (1) the generated music must be aesthetically pleasing, (2) the generated music must accurately reflect the changes that have occurred, and (3) a small group of musicians must be able to impersonate a large development team. We assess the feasibility of our approach using historical data from Eclipse, which yields promising results.
I translate Framework Design Guideline to Korean.
This Book is very impressed to me.
So I want to share Krzysztof Cwalina's Knowledge.
I re-edit his presentation and add my opinion.
There are tons of Software Development tools and selecting the best could be a challenge. Following is a curated list of the 21 top software development tools.
Visit On:- https://www.samaritaninfotech.com
Presentation at Android Builders Summit 2012.
Based on the experience of working with ODM companies and SoC vendors, this session would discuss how to figure out the performance hotspot of certain Android devices and then improve in various areas including graphics and boot time. This session consists of the detailed components which seem to be independent from each other in traditional view. However, the situation changes a lot in Android system view since everything is coupled in a mass. Three frequently mentioned items in Android engineering are selected as the entry points: 2D/3D graphics, runtime, and boot time. Audience: Developers who work on Android system integration and platform enablement.
A Software Factory Integrating Rational Team Concert and WebSphere toolsProlifics
Speakers: Greg Hodgkinson, Prolifics; Andre Tost, IBM
Description: Getting any software development team to effectively scale to meet the needs of a large integration project is actually harder than it sounds. For a large Automotive Retailer based in Florida, this is exactly what they needed to do. They needed a large amount of integration to be built between their brand new Point of Sales system and their new SAP back-end. In this session, you will hear about how tools such as Rational Software Architect and WebSphere Message Broker Toolkit were integrated with a Rational Team Concert-based development environment to set up super efficient software factory employing techniques such as Model-Driven Development and Continuous Integration to help this retailer keep their customers’ wheels on the road.
Microservices: How loose is loosely coupled?John Rofrano
Microservice architecture is a popular design pattern for DevOps deployments of cloud native applications. It's single purpose, loosely coupled, bounded context design lends itself to the independent life cycle required to quickly deploy and scale in the cloud. Docker containerization of these services further aids in the zero down-time deployments of these horizontally scalable services. But how do you keep them loosely coupled? How do they communicate without knowing about each other? and how do you keep all of those containers patched from new vulnerabilities that are being discovered every day?
This talk discusses the implementation of a Container Vulnerability Remediation Services that itself is designed as a collection of loosely coupled microservices that communicate via publish/subscribe messaging model using Kafka, Cloud Functions (OpenWhisk), and REST APIs implemented in Python Flask. This design keeps each microservice independent and replaceable, while enabling expandability for new services to participate in business functions without any pre-determined knowledge of the business workflow.
How Bankwest delivers business value through modern RESTful APIs with Java in...Rob Crowley
The Bankwest Core Banking System is based on loosely-coupled, CICS PL/I programs running on IBM System z. These have stood the test of time, running for more than 20 years and are still going strong today. With the advent of the burgeoning API economy, the time came to expose our Core Banking Data in a modern standards compliant manner direct to HTML5 apps and business partners. Whilst leveraging the existing PL/I programs, we wanted to dove-tail with modern RESTFul Web Services. This case study will cover how we've combined the light-weight Liberty Profile Application Server, a RESTful framework, CICS Channels and Containers and the JCICS library, to create a loosely-coupled modular architecture to deliver business value at pace.
At this joint NYC Cloud Foundry and NY PHP meetup, we'll discuss the shift to Platform-as-a-Service and what it means for PHP development on the cloud.
First, we'll take a look at the "traditional" cloud Infrastructure-as-a-Service (virtual servers and disks) model and describe how Platform-as-a-Service builds upon it to provide the runtimes and data services for hosting PHP applications.
We'll then demonstrate how a PHP developer can use buildpacks and services within a Cloud Foundry PaaS to deploy scalable and resilient apps to his or her cloud of choice.
Along the way we'll compare the variety of buildpacks available to PHP developers, show techniques for binding to services, and highlight best practices for creating born-on-the-cloud apps based on a microservices architecture.
Special thanks to Dan Mikusa for helping with the buildpack comparison.
PHP developers: Please give all three build packs a try. Provide your feedback and submit pull requests on GitHub.
The new buzz world in the world of Agile is "DevOps". So what exactly is devOps and Why do we need it? When development got married to deployment (sys-admin/operations) ; what is born is a new advanced species which is known to us today as "DevOps"
1. A Large-Scale Empirical Study of
the Relationship between Build
Technology and Build Maintenance
Shane Meiyappan Ahmed E. Bram Audris
McIntosh Nagappan Hassan Adams Mockus
3. What is a build system?
Source Deliverable
code
2
4. Build systems describe how sources
are translated into deliverables
.c .o .a
.cc .o .exe .deb
.tex .dvi .pdf
3
5. 1) Listen for 2) Build
changes changes
Continuous
Integration:
Enabled by
the build
system
4) Publish 3) Execute
results tests
4
6. The Build “Tax”
“...nothing can be said
to be certain, except
death and taxes”
- Benjamin Franklin
Up to 27% of source
changes require build
changes, too!
An Empirical Study of
Build Maintenance Effort
S. McIntosh, B. Adams, T. H. D.
Nguyen,Y. Kamei, A. E. Hassan
[ICSE 2011]
5
9. Low- Abstraction- Framework-
Level Based Driven
File-level Low-level scripts Assumes standard
dependencies are generated from project layout and
explicitly declared project metadata dependencies
Make
Rake
Autotools
Dependency Management
Automatically manages 3rd-
party API dependencies
8
10. Low- Abstraction- Framework-
Level Based Driven
File-level Low-level scripts Assumes standard
dependencies are generated from project layout and
explicitly declared project metadata dependencies
Make
Rake
Autotools
Dependency Management
Automatically manages 3rd-
party API dependencies
9
11. Low- Abstraction- Framework-
Level Based Driven
File-level Low-level scripts Assumes standard
dependencies are generated from project layout and
explicitly declared project metadata dependencies
Make
Rake
Autotools
Dependency Management
Automatically manages 3rd-
party API dependencies
10
12. Low- Abstraction- Framework-
Level Based Driven
File-level Low-level scripts Assumes standard
dependencies are generated from project layout and
explicitly declared project metadata dependencies
Make
Rake
Autotools
Dependency Management
Automatically manages 3rd-
party API dependencies
11
13. Low- Abstraction- Framework-
Level Based Driven
File-level Low-level scripts Assumes standard
dependencies are generated from project layout and
explicitly declared project metadata dependencies
Make
Rake
Autotools
Dependency Management
Automatically manages 3rd-
party API dependencies
12
14. Mining a Large-
Scale Corpus
Amassing and indexing a
large sample of version
control systems
Towards the census of public
source code history
A. Mockus [MSR 2009]
843,976 source
code repositories!
13
15. Software Forges
Mining a Large-
Scale Corpus
repo.or.cz
Amassing and indexing a
large sample of version
control systems
Towards the census of public
source code history
A. Mockus [MSR 2009]
843,976 source
code repositories!
13
16. Software Forges
Mining a Large-
Scale Corpus
repo.or.cz
Amassing and indexing a
large sample of version
control systems
Towards the census of public Software Ecosystems
source code history
A. Mockus [MSR 2009]
843,976 source
code repositories!
13
17. Software Forges
Mining a Large-
Scale Corpus
repo.or.cz
Amassing and indexing a
large sample of version
control systems
Towards the census of public Software Ecosystems
source code history
A. Mockus [MSR 2009]
843,976 source
Large Projects
code repositories!
13
18. Software Forges
Framework builds
tend to churn most repo.or.cz
Low−level Abstraction Frame Dependency
200
Build churn rate
100
0
Ant Jam Makefile Rake SCons Autotools CMake Maven Bundler Ivy
14
19. Source code coupling is Software Ecosystems
tightest with framework
and abstraction
1.2
1.0
0.8
0.6
0.4
0.2
−0.2
Low-level Framework Low-level Abstraction Low-level Abstraction
Apache − Ant vs. Maven Debian − Make vs. Autotools GNU − Make vs. Autotools
15