Monday, June 5, 2017

IEEE March/April Issue, Blog, and SE Radio Summary

Associate Editor: Brittany Johnson (@drbrittjaydlf)

The March/April issue of IEEE Software again presents readers with a range of software topics that are currently being explored, researched, and improved. Some of the articles in this issue discuss topics such as software testing and requirements, but the focus of this issue was crowdsourcing in software engineering.

Guest Editor Klaas-Jan Stol, Thomas LaToza, and Christian Bird introduced the feature topic in this issue with the article "Crowdsourcing for Software Engineering". In this article, the authors discuss what crowdsourcing is and introduce the articles in this issue that elaborate on new opportunities, and challenges, that come with crowdsourcing in software engineering. This issue includes the following articles on crowdsourcing in software engineering:


StackOverflow is becoming more popular as a data source to better understand how developers work, from understanding what prevents developers from posting questions and answers [1, 2] to what makes a good answer on StackOverflow [3]. The authors of "What Do Developers Use the Crowd For? A Study Using StackOverflow" took a slightly different approach from previous studies and explored in what situations developers use the crowd available on StackOverflow. Rather than mining StackOverflow responses, the authors mined GitHub commit histories looking for explicit mentions of StackOverflow in their commit comments. They found, as expected, that developer most often use the crowd on StackOverflow to gain knowledge on topics such as development tools, APIs, and operating systems. Other not so expected reasons that they found developers use StackOverflow includes promoting StackOverflow to other developers and providing rationale for a feature updates or additions. This is just one of the many areas of research that helps showcase the advantages of crowdsourcing for software engineering.

But of course, as with any new research direction or opportunity, there needs to be research that explores the challenges that come with it. The article "Barriers Faced by Newcomers to Software-Crowdsourcing Projects" sheds some light on barriers encountered by newcomers on software projects that use crowdsourcing to implement parts of their project. The authors conducted quantitative and qualitative analyses, and found that some of the more frequent barriers that newcomers encounter include issues like lack of documentation, poor task management, and problems understanding the code structure or architecture. The authors also propose some guidelines for how we might help developers overcome these barriers. One of their proposed guidelines suggests that task management can be improved by better matching tasks to developers with the necessary expertise. The authors suggest using task complexity to determine tasks appropriate for newcomers. Another alternative, as suggested by existing research, would be to determine newcomer expertise and find tasks that match their expertise [4]. They key is to be able to help others more efficiently contribute to software-crowdsourcing projects.

This was a particularly special issue, as the editors included a special thanks from the editors to the numerous people that reviewed articles for the magazine in the past year. Another thanks to those who have taken time to help make IEEE Software great!

IEEE Software Blog

There are some interesting posts featured for March and April, mostly focused on frameworks and tools for improving the software development process. Peter Chen of Queen's University discussed a framework called CacheOptimizer that provides instrumentation for finding optimal cache configurations when using application-level caching frameworks. Yossi Gil and Matteo Orrû presented a tool called The Spartanizer. Their tool helps developers code in the "Spartan Programming Style" -- in this style of coding, programmers phrase their code statements such that they say the most in the fewest words. Finally, Mark Basham of Diamond Light Source discussed ways we can scale up the software development process, recommending revisiting classic CS books such as "The Mythical Man Month" and "Peopleware".

SE Radio

In this issue, SE Radio welcomed a new host, Kim Carter. For his first SE Radio episode, Kim spoke with Francois Raynaud on DevSecOps and improvements that should be made to existing delivery approaches. In March and April, SE Radio also featured episodes pertaining to system quality, including episodes on testing, system failures, and distributed storage.
There are also some episodes in this issue for learning new skills or technologies, including an intro to machine learning with Katie Malone and success skills for architects with Neil Ford.



[1] Ford, D., Smith, J., Guo, P. J., & Parnin, C. (2016, November). Paradise unplugged: Identifying barriers for female participation on stack overflow. In Proceedings of the 2016 24th ACM SIGSOFT International Symposium on Foundations of Software Engineering (pp. 846-857). ACM.
[2] Asaduzzaman, M., Mashiyat, A. S., Roy, C. K., & Schneider, K. A. (2013, May). Answering questions about unanswered questions of stack overflow. In Mining Software Repositories (MSR), 2013 10th IEEE Working Conference on (pp. 97-100). IEEE.
[3] Nasehi, S. M., Sillito, J., Maurer, F., & Burns, C. (2012, September). What makes a good code example?: A study of programming Q&A in StackOverflow. In Software Maintenance (ICSM), 2012 28th IEEE International Conference on (pp. 25-34). IEEE.
[4] Johnson, B., Pandita, R., Murphy-Hill, E., & Heckman, S. (2015, August). Bespoke tools: adapted to the concepts developers know. In Proceedings of the 2015 10th Joint Meeting on Foundations of Software Engineering (pp. 878-881). ACM.
Posted by at No comments:

Sunday, May 21, 2017

How Cross-stack Configuration Errors can Ruin a 360 Degree Panorama Website

by Mohammed Sayagh, Ecole Polytechnique de Montréal.

Associate Editor: Sarah Nadi, University of Alberta (@sarahnadi)


Wordpress user “msayagh” could not upload his latest 360 degree panorama of Buenos Aires’ Plaza de Mayo to his Wordpress site (Figure 1). That's strange, since he was using the well-known “NextGen” Wordpress plugin. Being a software engineer at heart, and PhD student at work, he delved into the plugin’s source code, without finding any clue. Little did he know that the NextGen problem was not due to a source code problem, but due to an incorrect configuration option.

Basically, software configuration is the mechanism used to adapt a software system to different situations. For example, one has to only change an option like “file_uploads” to enable/disable file uploads in a particular system. While this gives a lot of flexibility to people to customize their system, it also means that assigning a wrong value to one option can lead the software to an incorrect behaviour. In the research literature, researchers found that such errors are frustrating as they are severe and require a lot of efforts to be fixed.
Figure 1: Configuration error encountered by msayagh’s 360 degree panorama.

Unfortunately, msayagh’s configuration error was not an ordinary configuration error, because only much later was the poor student able to find that the misconfigured option was not an option of “NextGen”, but of the PHP interpreter. That’s right! Although the error message popped up in NextGen’s GUI layer, the actual configuration option causing the trouble had to be fixed much deeper inside the Wordpress LAMP stack (Fig. 2). In other words, a particular system’s configuration is determined by the integration of configurations of each layer in a stack, i.e., each layer’s configuration is linked to each other (more on that later).

Figure 2: LAMP Stack Architecture


Was msayagh just using the wrong Wordpress plugin on the wrong day, or are cross-stack configuration errors a fundamental problem? By manually studying 1,082 configuration errors from StackOverflow and StackExchange, he found that cross-stack configuration errors are intrinsically more severe than single-layer errors and often occur during devops operations [1]. On the other hand, single-layer errors particularly occur during the setup of an environment and the maintenance of a website, which is indeed less severe.

Heartbroken from the 360 degree panorama incident, msayagh started working on an approach to help other Wordpress users like himself to debug cross-stack configuration errors using modern source code analysis techniques. He observed how existing analysis techniques only targeted single-layer errors, yet were quite good at that. For example, let’s consider the example of Figure 3 with three stack layers, each of which use a given programming language (PHP and C) and have their own configuration options.

Figure 2: LAMP Stack Architecture.

Was msayagh just using the wrong Wordpress plugin on the wrong day, or are cross-stack configuration errors a fundamental problem? By manually studying 1,082 configuration errors from StackOverflow and StackExchange, he found that cross-stack configuration errors are intrinsically more severe than single-layer errors and often occur during devops operations [1]. On the other hand, single-layer errors particularly occur during the setup of an environment and the maintenance of a website, which is indeed less severe.

Heartbroken from the 360 degree panorama incident, msayagh started working on an approach to help other Wordpress users like himself to debug cross-stack configuration errors using modern source code analysis techniques. He observed how existing analysis techniques only targeted single-layer errors, yet were quite good at that. For example, let’s consider the example of Figure 3 with three stack layers, each of which use a given programming language (PHP and C) and have their own configuration options.

Figure 3:Simplified source code of 3 LAMP stack layers (left) with their corresponding dependency graphs (right).

To analyze this example, a single layer approach for a given layer would rely on a graph model of the layer’s data [2] and control-flow dependencies [3], as shown on the right side of Figure 3. If the misconfigured option (i.e., the option that msayagh would like to find using his approach) in the example is “Option4” and the error message is printed by the print statement circled in red, a single-layer approach would very efficiently perform a breadth-first search starting from the circled node trying to find nodes that use a given option node, yielding only “Option2” (i.e., a false alarm). If there would only be a way to “link” the middle layer’s dependency graph to the graphs of upper and lower layers, the code accessing Option4 (i.e., the culprit option) would have been found!

At this point, msayagh suddenly realized that the missing links in the graphs are in fact the “Physical Links” between layers of a stack, such as the calling conventions from a plugin to Wordpress, or from a PHP program to the language primitives implemented in C. Since such links are documented (or in the worst case can be found in the stack layers’ code), they are straightforward to find and add to the dependency graph (see Figure 4). For example, the function “bar()” in the top layer is connected to its implementation “php_bar()” the lower layer by following a common naming convention in PHP. Similarly, we have the connections between the call to the function “mysql_bar()” and its implementation in the lower layer. By performing a simple breadth-first traversal of the unified stack dependency graph, the approach now yields (in that order) Option 4, Option1/2 and Option 3, with the first recommendation being the right answer. Since this new approach basically reuses the results of existing single-layer approaches, it is easy to generate the dependency graphs of additional layers or swap a single-layer approach for an equivalent one.
Figure 4: Model with “Physical links”

The approach basically reports as output the suspected configuration options to have an incorrect value. While the first reported option is the most likely to be misconfigured, the last one is the least likely.

Being an empirical researcher, msayagh evaluated the effectiveness of his approach on 36 real Cross-stack configuration errors, and found that the approach was able to identify the misconfigured option for 32 cases, with 23 misconfigured options reported as top recommendation. Each time, the approach finished its analysis in a median time of 230 seconds (asking a question on StackOverflow would have taken a median of 2.33 hours, without a strong guarantee of correctness).

In other words, in less than 4 minutes, our approach would enable any Wordpress user to upload their favourite 360 degree panoramas, or configure any other plugin in their Wordpress system! For more details, please see our ICSE 2017 paper [1] or if you happen to be in Bueones Aires next week, come see our presentation!

References:
[1] Mohammed Sayagh, Noureddine Kerzazi, Bram Adams, “On Cross-stack Configuration Errors”, in Proc. of the 39th ICSE, 2017. Link: http://mcis.polymtl.ca/publications/2017/icse.pdf
[2] Data flow: https://en.wikipedia.org/wiki/Data_flow_diagram
[3] Control flow: https://en.wikipedia.org/wiki/Control_flow_graph
Posted by at No comments:

Sunday, April 2, 2017

Scaling up the software development process

by Mark Basham, Diamond Light Source (@basham_mark)
Associate Editor: Christoph Treude (@ctreude)
 
What should I talk about at the first RSE conference in the UK?

New conferences don't start every day, and so when a community which you have been a part of for a while decides to run one and asks for abstracts, it's important to take part.  The community I’m talking about is the UK’s RSE or Research Software Engineer community, and it has been gathering strength over the last few years.  Originally started by the SSI (Software Sustainability Institute, www.software.ac.uk) the initial aim of the group was to create a job title and career path for the oft underappreciated group of researchers who support their research group by writing and maintaining, often critical, software.  Given this audience the question is really what should I talk about?  I contribute to several open source software packages, which could always do with more publicity (www.dawnsci.org, https://github.com/DiamondLightSource/Savu), but that felt like a shameless plug which would only interest a very minor group, and I wanted something which would appeal to a larger audience.

Project Management?

One more general area in which I have been working is project managing a large cross group software project at Diamond Light Source (www.diamond.ac.uk).  When I started working the project about 2 years ago, I had little experience of project managing such a complex project, although Diamond runs projects routinely.  I cannot understate that the amount I have learnt from my peers at Diamond whilst making the transition from developer to manager during this project is huge, and wasn't long before I was directed towards a selection of texts in the field.  The wealth of information available on the topic is absolutely astounding, and almost immediately influenced my management decisions, but coming from my background as a scientist, this wealth of knowledge had passed me by almost entirely.  It seemed like exactly the kind of thing on which to base a presentation.

The Books?

There are many good books about project management for software, but the ones which I discovered and found particularly relevant were the Mythical Man Month, Peopleware, and User Story Mapping.

The Mythical Man Month

This book is from the 70s but still has many relevant points for the modern developer.  The key take home for me was that if you want to write software well, as in tested, integrated and ready for others to use, it takes about 10 times longer than to just hack it up.

Peopleware

This is a great book, and I have enjoyed other books by the Atlantic Systems Guild, such as “Adrenaline Junkies to Template Zombies” and “Slack”.  The thing that resonated with me here was how damaging context switching was, and it is something I see regularly in our predictably overstretched team.

User Story Mapping

The last book I wanted to talk about was User Story Mapping, simply because getting requirements right is always difficult, and the book suggested a clear and concise method for doing this, as well as a nice discussion on the merits and pitfalls of user stories.

So what are you going to talk about?

OK, so three books do not make a presentation, but they do lay the foundations for a talk based around work we conducted at Diamond to try to get the aforementioned project back on track.  There was one deliverable which for many valid reasons was falling behind the rest of the project, and put the whole initiative in jeopardy.  Diamond took action. First we identified a team, and freed up their time to focus on the deliverable to stop them from having to multitask.  We moved them out of their usual open plan environment and into a new office for the duration of the intervention, increasing their workspace by around 70% and reducing off topic distractions.  Finally we trialled a new method for identifying requirements and planning the work based on the Story Mapping approach.  The cost of these interventions was high, but the result was significant, bringing the deliverable back on track with a generally high level of design, code quality and tests in place. This journey seemed like a perfect topic for a talk to a growing community which may meet similar challenges.

Final Title?

“Scaling up the software development process, a case study highlighting the complexities of large team software development” (https://arxiv.org/abs/1703.00958).  Personally I enjoyed preparing it, and the associated paper is available if you are interested in the results of the experiment.
Posted by at No comments:

Monday, March 20, 2017

IEEE January/February Issue, Blog, and SE Radio Summary

Associate Editor: Brittany Johnson (@brittjaydlf)

The January/February issue of IEEE Software continues to deliver new and exciting things happening in the software world. This issue covers a few different of topics, such as global software engineering and software requirements, but focuses on software engineering for the internet of things. A large subset of the articles in this issue pertain to this topic.

This issue features an article on requirements engineering titled "Guidelines for Managing Requirements Rationale" by Anil Kumar Thurimella, Mathias Schubanz, Andreas Pleuss, and Goetz Botterweck. In this article, the authors discuss both the challenges involved in requirements rationales along with detailed guidelines for creating them. Based on the article, the guidelines presented are best suited for organizations that require both transparency and well thought out decisions.

Most of the papers in this issue discuss challenges and concerns that need to be addressed when software engineering for the Internet of Things (IoT). Aside from the introduction to this issue's focus, titled "Software Engineering for the Internet of Things" by Xabier Larrucea, Annie Combelles, John Favaro, and Kunal Taneja, this issue features the following articles on the IoT:

Some articles provide general suggestions for IoT software engineering. For example, in "Scalable-Application Design for the IoT", Vankatesh and colleagues propose a modular approach to designing and implementing context-aware IoT applications. Given the dynamic nature of IoT applications and large amounts of raw data produced, scalability becomes an important issue to address early on in the design of IoT applications. The authors propose and analyze an approach that uses context engines, or small and simple functional units, to improve scalability in context-aware IoT applications.

In "Key Abstractions for IoT-Oriented Software Engineering", Zambonelli presents common feature across IoT software and applications to determine the important abstractions for engineering IoT software. The common features he discusses come from existing IoT research on designing and developing IoT systems. Based on the common features, such as "things" and software infrastructure "glue", the author identified the following key abstractions to consider during analysis, design, and development of IoT systems: Stakeholders and Users (Analysis), Requirements (Analysis), Groups and coalitions (Design), Avatars (Design and Development), and Smart Things (Development).

With any growth and change come challenges that must be overcome. In the article "A Roadmap to the Programmable World: Software Challenges in the IoT Era", Taivalsaari and Mikkonen provide a forward-looking roadmap to a programmable world and discuss some of the challenges software developers may face along the way.  The authors highlight the differences between IoT and typical software development, such as the system of devices that comprise an IoT application, and implications of these differences along with possible challenges. Some of the challenges highlighted in this article include considerations for multi-device programming, security of IoT systems, and dealing with the distributed, dynamic, and potentially migratory nature of IoT software.

IEEE Software Blog

The blogs posts from the past couple months continue to reflect on and discuss the state of software development and provide insights into new technologies and approaches relevant to the work we do. January's blog posts focus on recent innovations in new and old technologies. Most interesting is a new tool introduced called the Unified ASAT Visualizer (UAV) which is used for comparing multiple static analysis tools on a given project. This aims to developers decide whether the costs for using more than one tool (i.e. FindBugs + Checkstyle) are worth it. February touches on the theme from the IEEE Software focus topic, Internet of Things, but also discusses other topics such as rethinking the role of developers in OSS and sustainable software design.

SE Radio

Featured on SE Radio this issues is a range of topics. Most of the episodes in this issue focus on software integrity, from testing and dealing with bugs and failures to dealing with the challenges in debugging distributed systems. Invited guests include Florian Gilcher, Gerald Weinberg, James Whittaker, Donny Nadolny, Alexander Tarlinder, John Allspaw, and James Cowling. Also, SE Radio welcomed a new member to the SE Radio Team, Edaena Salinas! 
Posted by at No comments:

Sunday, March 12, 2017

The Spartanizer

Authors: Yossi Gil and Matteo Orrù, Technion, Israel

In this post, we would like to tell you about the Spartanizer, an automatic software-engineering tool developed at the Technion, that helps you code in the “Spartan Programming Style” that means that a programmer phrases his code’s statements in the same way a person of Laconia phrases his statements of speech:

saying the most in a few, clear words.
For example, the Spartanizer takes some verbose piece of code such as
public static String getCurrentLanguage()
{
  String language;
  if (getBooleanProperty("lang.usedefaultlocale"))
    {
language = Locale.getDefault().getLanguage();
    }
    else
    {
language = getProperty("lang.current", "en");
    }
  return language;
}
Figure 1: An example taken from jEdit
(found in the Jedit project), and converts it  into the concise spartan form;
public static String getCurrentLanguage() {
 return getBooleanProperty("lang.usedefaultlocale")
           ? Locale.getDefault().getLanguage()
           : getProperty("lang.current", "en");
}
Figure 2: The spartanized code of Figure 1
Transformations made by the Spartanizer are too many (currently over 150) to enumerate here; their main kinds are compile time evaluation when possible, elimination of dead code, simplification of boolean expressions, removing syntactic baggage such as superfluous call to super(), short-circuiting and early returns, identifying cases in which a for should have been used instead of a while, using standard short names whenever this makes sense.  A frequently recurring theme is refactorings inspired by the distributive rules of arithmetic, ab+ac⇒a(b+c) and ba+ca⇒(b+c)a i.e., identifying a common factor of two
syntactical elements and rewriting it in equivalent way with this common factor occurring only once. The Spartanizer is thus able to unite two adjacent conditionals, factor out commonalities of the two branches of a conditional. Yet another kind of refactorings carried out by the spartanizer are applying programming idioms whenever appropriate, e.g., following fluent API programming style.
The code generated by the Spartanizer is concise, and often looks more functional than imperative, and may need some getting used to conventions. Yet, our experience in teaching spartanization, and applying it in student and non-student projects, including several projects with a couple of hundreds of classes each, shows that after adjustment period is short, and programmers tend to prefer minimal ink to verbosity, as long as the minimal like is regular, i.e., follows a small set of recurring patterns. An empirical study [1] shows that the spartanization of code makes it measurably more predictable.
Spartanized code has unique lean appearance: few statements, minimal number of intermediates, adherence to idioms, use of conditional expressions (and in recent versions Java streams) rather than explicit, general purpose, control such as if, else, while, and for. In fact, spartanized code often assumes the concise and elegant looks of functional programs, even though the original version of the code was purely imperative. For example, this function  for comparing two lists of nodes  (drawn from the Spartanizer’s implementation) was created  automatically from its imperative version.
<N extends ASTNode> boolean same(final List<N> ns1, final List<N> ns2) {
  return ns1 == ns2 ||
    ns1.size() == ns2.size() &&
       range.from(0).to(ns1.size())
        .stream()
        .allMatch(λ -> same(ns1.get(λ), ns2.get(λ)));
 }
Figure 3: An example of spartanized code taken from the Spartanizer project
Conversion can be done either interactively, or in batch form. The Spartanizer features an Eclipse plugin, which offers “spartanization” tips to the programmer. The programmer will reach the concise form by following the six tips offered by the Spartanizer to the jEdit function in Figure  Figure. Unlike many code analysis and code generation tools, the conversion from the verbose to the concise is continuous: one little change at a time. An experimental feature in the Spartanizer, available from version 2.8 is capable of doing the opposite conversion, from the concise to the verbose, making it possible for the programmer to use the mouse wheel for both zooming in and zooming out the code.
Alternatively, spartanization can be done in batch application. Unlike many deep analysis tools automatic spartanization is fast, with more than five thousand tips per minute on a contemporary computer.  Like other refactoring tools, the Spartanizer is optimistic, making e.g. some assumptions on the use of overloading, or that the order of evaluation of arguments to a function is immaterial to correctness.
Internally, the Spartanizer follows this extensible modular structure: spartanization tips are generated by small software modules, called tippers. Each of these generate its own kind of spartanization tips. Tippers are applied automatically or interactively by tip applicators, which apply automatic spartanization to user selected portions of the code (function, class, file or project).
The Spartanizer is available at the Eclipse marketplace, and open source on GitHub.
References
[1] Y. Gil and M. Orrú, “Code Spartanization,” in Proc. of SAC’17, the 32nd ACM Symposium on Applied Computing, Marrakesh, Morocco, April 3–7 2017.
[2] Y. Gil and M. Orrú, “The Spartanizer: Massive Automatic Refactoring,” in Proc. of 24th IEEE International Conference on Software Analysis, Evolution, and Reengineering, Klagenfurt Austria, February 20-24, 2017.
[3] The Spartanizer at the Eclipse Marketplace. https://marketplace.eclipse.org/content/spartan-refactoring-0
[5] The Spartanizer website: http://spartan.org.il/
Posted by at No comments:
Subscribe to: Posts (Atom)