Configuration Management: NASA finds lost mission (IMAGE satellite)...

NASA finds lost IMAGE satellite thanks to an amateur astronomer and is not sure that communications will be possible (configuration management issue?):

• https://www.theregister.co.uk/2018/01/30/zombie_satellite_is_image/

Quoting:

"NASA finds satellite, realises it has lost the software and kit that talk to it. Vanished IMAGE now found. Don't suppose anyone kept a copy of its comms code?" 

(...)

"The Goddard boffins next need to undertake what the agency called “significant reverse-engineering” to capture and analyse data from the signal.

“The challenge to decoding the signal is primarily technical,” the announcement said. “The types of hardware and operating systems used in the IMAGE Mission Operations Centre no longer exist, and other systems have been updated several versions beyond what they were at the time”.

If NASA can decode data from the satellite, it will then try to turn on the science payload “to understand the status of the various science instruments”, and make a decision about IMAGE's future."

Update (2018-01-31) - Additional source for the same news:

• https://www.engadget.com/2018/01/31/nasa-makes-contact-with-satellite-lost-in-space-13-years-ago

REPORT: State of Testing report (PDF)

State of Software Testing Report 2017:
http://qablog.practitest.com/wp-content/uploads/2017/03/State_of_testing_2017_final_report.pdf

And the 2018 edition in the preparation:
http://qablog.practitest.com/state-of-testing/

Quoting;
"What is the State of Testing?
The State of Testing™ seeks to identify the existing characteristics, practices, and challenges facing the testing community in hopes to shed light and provoke a fruitful discussion towards improvement.
The final report is translated into several languages and shared globally, further expanding the reach and impact this report has on all of us in the QA world.
This is the 5th year that the QA Intelligence Blog is running this survey in collaboration with TeaTime with Testers, and with your help,  it can be bigger and more comprehensive than in previous years.
Each year the amount of participants has increased, and the final reports become even more valuable as a culminated reflection of testing trends, challenges, and characteristics."

BOOKS: TOCs of some of the most relevant SW Engineering books

The table of contents (TOC) of some the most relevant SW Engineering books mostly coincide, which is a good thing in the sense that it may point that the topic is getting "stabler".  Three of the most commonly used text books for software engineering courses are:

• Software Engineering - I. Sommerville, 9 ed.: Pearson, 2010
• Essentials of Software Engineering - Frank Tsui; Orlando Karam; Barbara Bernal, 3 ed., Jones & Bartlett Learning
• Software Engineering. Modern Approaches - E. J. Braude and M. E. Bernstein, 2 ed.: Wiley, 2011.

And the TOCs include...

Software Engineering, I. Sommerville, 10 ed.: Pearson, 2015

Ch. 1: Introduction Ch. 2: Software Processes Ch. 3: Agile Software Development Ch. 4: Requirements Engineering Ch. 5: System Modeling Ch. 6: Architectural Design Ch. 7: Design and Implementation Ch. 8: Software Testing Ch. 9: Software Evolution
Ch. 18: Service-oriented Software Engineering Ch. 22: Project Management Ch. 23: Project Planning Ch. 25: Configuration Management

Essentials of Software Engineering 

Ch. 1: Writing a program Ch. 2: Building a System Ch. 3: Engineering of Software Ch. 4: Software Process Models Ch. 5: New and Emerging Methodologies (Agile) Ch. 6: Requirements Engineering Ch. 7: Design: Architecture and Methodology Ch. 8.5: User Interface Design Ch. 9: Implementation Ch. 10: Testing and Quality Assurance Ch. 11: Configuration Management, Integration and Builds Ch. 12: Software Support and Maintenance Ch. 13: Software Project Management
Appx A: Software Development Plan (SDP) Appx B: Software Requirements Specifications (SRS) Appx C: Software Design (SDD) Appx D: Software Test Plan (STP) Essentials of Software Engineering, Frank Tsui; Orlando Karam; Barbara Bernal, 3 ed., Jones & Bartlett Learning

Software Engineering. Modern Approaches, E. J. Braude and M. E.Bernstein, 2 ed.: Wiley, 2011.

Ch. 1: Introduction to Software Engineering Ch. 2: Introduction to Quality and Metrics in Software Engineering Ch. 3: Software Process Ch. 4: Agile Software Processes Ch. 5: Quality in the Software Process Ch. 6: Software Configuration Management Ch. 7, Ch. 8.2-3: Principles of Software Project Management Ch. 10: Principles of Requirements Analysis Ch. 11: Analyzing High-Level Requirements Ch. 12: Analyzing Detailed Requirements Ch. 16: The Unified Modeling Language Ch. 18: Software Architecture Ch. 22.1-9: Principles of Implementation Ch. 25: Introduction to Software Testing Ch. 26.1-4: Unit Testing Ch. 27.1-6: Module and Integration Testing Ch. 28.1-2,4: Testing at the System Level Ch. 29: Software Maintenance

Source:
https://www.halvorsen.blog/ and Amazon Web Site.

BOOK: Introduction to Statistical Quality Control (Douglas C. Montgomery)

AKA as "the bible" for statistical concepts (now in the 7th edition):

• Statistical Quality Control: Douglas C. Montgomery: 9781118146811: Amazon.com: Books (7th edition)
• Amazon.com: Introduction to Statistical Quality Control (0352030000810): Douglas C. Montgomery: Books (6th edition) 

Quoting: 

"The trusted guide to the statistical methods for quality control.

Quality control and improvement is more than an engineering concern. Quality has become a major business strategy for increasing productivity and gaining competitive advantage. Introduction to Statistical Quality Control, Sixth Edition gives you a sound understanding of the principles of statistical quality control (SQC) and how to apply them in a variety of situations for quality control and improvement.

With this text, you'll learn how to apply state-of-the-art techniques for statistical process monitoring and control, design experiments for process characterization and optimization, conduct process robustness studies, and implement quality management techniques.

You'll appreciate the significant updates in the Sixth Edition including:
* In-depth attention to DMAIC, the problem-solving strategy of Six Sigma. It will give you an excellent framework to use in conducting quality improvement projects.
* New examples that illustrate applications of statistical quality improvement techniques in non-manufacturing settings. Many examples and exercises are based on real data.
* New developments in the area of measurement systems analysis
* New features of Minitab V15 incorporated into the text

* Numerous new examples, exercises, problems, and techniques to enhance your absorption of the material"

PS. Now minitab is at V18. Minitab is a statistical package software (similar to SPSS).

Static Analysis: FB Infer static analyzer now ships with RacerD for detecting race conditions (which are multi-threading issues)

Ah well, it feels good when big companies give back?... Maybe. Could be better. But this is better than nothing. :)

Facebook open-sourced Infer, a static analysis tool it uses for itself and now it ships with RacerD for detecting race conditions (as a code review bot). Sample code for detectable situations can be found here:

• https://www.infoq.com/news/2018/01/java-concurrency-infer-racerd

About the FB Infer static analysis tool:

• Infer static analyzer | Infer

Quoting (the first link):

"Facebook’s open-source static analysis tool, Infer, now ships with support for detecting race conditions in Java code via RacerD. RacerD identifies race conditions between methods in classes that use locks or the @ThreadSafe annotation.

Facebook has used RacerD in its own production code for the last year identifying more than 1,000 multi-threading issues, all before code ever reached production. This concurrency checking capability is now available to Java developers who use Infer to detect bugs in Java code.

A race condition is a type of concurrency error or bug that occurs when two threads operate on the same object without proper synchronization, causing their executions to overlap each other, and at least one of the accesses is a write. Concurrency issues are hard to debug and even harder to reproduce after encountered.

RacerD performs fast, useful concurrency analysis at scale. RacerD is fast because it doesn't try to check an entire code base for concurrency issues; it only examines the code that it believes can be run concurrently.

RacerD identifies code that can run concurrently by looking for classes, methods, and interfaces that have been explicitly annotated with the @ThreadSafe annotation or that create a lock via the synchronized keyword. When a class or interface is annotated with @ThreadSafe, all subclasses of the class/implementation are also evaluated. To increase code coverage with RacerD, additional optional annotations may be useful: @ThreadConfined, @Functional, @ReturnsOwnership, or @VisibleForTesting."
(...)

Situations not detected (quoting): 

"RacerD is currently limited to checking for data races only;

• it doesn't check for other concurrency issues like deadlock and atomicity. 

RacerD also misses data races that are due to:

• aliasing
• locally declared objects escaping its scope
• accesses protected by different locks
• local objects containing non-owned objects
• weak memory and Java’s volatile keyword"

Automated Quality Characteristic Measures (AQCM from CISQ - Consortium for IT Software Quality)

Complementing the AFP and AEP standards from CISQ, the Automated Quality Characteristic Measures (AQCM) is also worth mentioning:

• Automated Quality Characteristic Measures | CISQ - Consortium for IT Software Quality

Quoting:
"CISQ has developed Automated Quality Characteristic Measures to measure and manage the structural quality of IT application software. The automated measures for Security, Reliability, Performance Efficiency, and Maintainability are now OMG® approved standards making them global standards for use by IT organizations.

These measures were developed from coding rules covering some of the most serious violations of good architectural and coding practices that should be avoided and can be detected through static code analysis. Each measure counts the number of violations of the architectural and coding rules related to that quality characteristic and then can be used in creating metrics for defect density, etc.

Security	Critical security violations in the source code drawn from the Top 25 security weaknesses in the Common Weakness Enumeration (CWE) repository
Reliability	Critical violations of availability, fault tolerance, and recoverability of software
Performance Efficiency	Critical violations of response time, as well as processor, memory, and utilization of other resources by the software
Maintainability	Critical violations of modularity, architectural compliance, reusability, analyzability, and changeability in software (...)"

SW Construction: Java Coding Conventions (by Google)

The short story

Here are the Google Java Coding Conventions. made to be easily understood and enforceable (automatically), they are a good insight on what a big company defined as best practices for coding on a certain (widely popular) language:

https://google.github.io/styleguide/javaguide.html

Quoting:
"Google's coding standards for source code in the Java™ Programming Language. A Java source file is described as being in Google Style if and only if it adheres to the rules herein.

Like other programming style guides, the issues covered span not only aesthetic issues of formatting, but other types of conventions or coding standards as well. However, this document focuses primarily on the hard-and-fast rules that we follow universally, and avoids giving advice that isn't clearly enforceable (whether by human or tool)."

Is your project following any best practices at all? Are they written? Who wrote them? Do you use them at will or is there someone who enforces them? If the answers to those questions are not clear on your mind, read the long story below.

The Long Story

Your company, your department (Domain Expert, CTO, etc.) or even only your PM and TM could define as coding conventions some external document (or standard) to follow during project execution. The advantage could be that you are reusing (documentation) - and thus saving money - as well as saving you - or your team / department - the hassle of keeping it internally updated. 

The other advantage is that, if rightly chosen, nobody will question the authority of such a document (while an output of former teams, projects and/or internal experts) could suffer from that lack of authority and general trustworthiness by everyone involved.

Enforcing the coding standard (coding conventions) into a tool like CheckStyle (that could be inserted as an integration task in the Continuous Integration server) is also a good idea because early deviations will have to be fixed by the team (you could make the build fail if a rule - even a formatting one - is broken). 

Updated: 2018-01-07, short and long story.

Conference: CppCon (C++, US)

The conference for C++ is CppCon. If you want to hear (and see) the author of the language speaking, see the conference archive:
https://cppcon.org/

Quoting:
"In the meantime, look for slides and source code for your favorite CppCon 2017 sessions at our presentation material repository.

You can find the posters that were entered in the CppCon 2017 Poster Competition in the poster repository.

You can also watch CppCon 2017 session videos on YouTube and Channel 9. Some of them are already available on the CppCon YouTube channel in the CppCon 2017 playlist."

SW Construction: Angular CLI (web app generator tutorial)

http://www.dotnetcurry.com/angularjs/1409/angular-cli-tutorial

Citando:
"Introducing Angular CLI

As many of you would know, building a modern web application using a front-end framework like Angular is no more as simple as developing few html pages and showing them on the browser. To work with modern JavaScript frameworks, you now need an environment to be set on the machine, as well as an environment for the application inside the folder that has to contain the code.

The following list shows the required tools to build an Angular application at a higher level:

• The system to be used for development should have Node.js installed on it. Node.jsis a server platform that supports building web servers using JavaScript. It is also widely used as a platform to build web applications, as it is very easy to spin up a server and start it instantly on Node.js.
• A Node.js based package manager like npm or yarn is needed to install the libraries to be used in the application.
• The application needs a setup to install a set of required packages containing the library files, tools to compile the TypeScript code, bundle the files together, run unit tests, start a web server and build files to deploy the application. While setting up these tasks has become easier with tools like Grunt, Gulp and Webpack, one still needs to spend time in writing the scripts for these tasks in every new project.

The third point of the above list takes a lot of time and effort.

To reduce this pain, the Angular team created Angular CLI. Angular CLI is a generator that makes the process of building an Angular application easier."