Seyfert's Sextet: where is the gas?

Seyfert's Sextet (a.k.a HCG 79) is one of the most compact and isolated galaxy groups in the local Universe. It shows a prominent diffuse light component that accounts for ~50% of the total observed light. This likely indicates that the group is in an advanced evolutionary phase, which would predict a significant hot gaseous component. Previous X-ray observations had suggested a low luminosity for this system, but with large uncertainties and poor resolution. We present the results from a deep (70 ks), high resolution Chandra observation of Seyfert's Sextet, requested with the aim of separating the X-ray emission associated with the individual galaxies from that of a more extended inter-galactic component. We discuss the spatial and spectral characteristics of this group we derive with those of a few similar systems also studied in the X-ray band. The high resolution X-ray image indicates that the majority of the detected emission does not arise in the compact group but is concentrated towards the NW and corresponds to what appears to be a background galaxy cluster. The emission from the group alone has a total luminosity of ~1x10^40 erg/s in the (0.5-5) keV band. Most of the luminosity can be attributed to the individual sources in the galaxies, and only ~2x10^39 erg/s is due to a gaseous component. However, we find that this component is also mostly associated with the individual galaxies of the Sextet, leaving little or no residual in a truly IGM component. The extremely low luminosity of the diffuse emission in Seyfert's Sextet might be related to its small total mass.Comment: 8 pages, 7 figures. Accepted on A&

Managing Technical Debt in Software Engineering

Sustainable and scalable software systems require careful consideration over the force known as technical debt, i.e., the additional project cost connected to sub-optimal technical decisions. However, the friction that software systems can accumulate is not connected to technical decisions alone, but reflects also organizational, social, ontological and management decisions that refer to the social nature and any connected social debt of software – this nature is yet to be fully elaborated and understood. In a joint industry & academia panel, we refined our understanding of the emerging notion of social debt in pursuit of a crisper definition. We observed that social debt is not only a prime cause for technical debt but is also tightly knit to many of the dimensions that were observed so far concerning technical debt, for example software architectures and their reflection on organizations. Also we observed that social debt reflects and weighs heavily on the human process behind software engineering, since it is caused by circumstances such as cognitive distance, (lack of or too much of) communication, misaligned architectures and organizational structures.The goal for social debt in the next few years of research should be to reach a crisp definition that contains the essential traits of social debt which can be refined into practical operationalizations for use by software engineering professionals in need of knowing more about their organizational structure and the properties/cost trade-off that structure currently reflects.</p

Dimensions of Consistency in GSD: Social Factors, Structures and Interactions

Peer reviewe

Software architecture social debt:managing the incommunicability factor

\u3cp\u3eArchitectural technical debt is the additional project cost connected to technical issues nested in software architectures. Similarly, many practitioners have already experienced that there exists within software architectures a form of social debt, that is, the additional project cost connected to sociotechnical and organizational issues evident in or related to software architectures. This paper illustrates four recurrent antipatterns or community smells connected to such architectural social debt and outlines a means to measure the additional project cost connected to their underlying cause: decision incommunicability. Evaluating the results in multiple focus groups, this paper concludes that studying social debt and community smells at the architecture level may prove vital to rid software development communities of critical organizational flaws incurring considerable additional cost.\u3c/p\u3

Cognitive distance and research output in computing education: a case-study

IEEE Contribution: This paper quantifies the phenomenon of more versus better research output in computing research education and elaborates on how the organizational variable known as cognitive distance plays a fundamental role in mediating such more versus better research output relation

Defining, enforcing and checking privacy policies in data-intensive applications

\u3cp\u3eThe rise of Big Data is leading to an increasing demand for large-scale data-intensive applications (DIAs), which have to analyse massive amounts of personal data (e.g. customers' location, cars' speed, people heartbeat, etc.), some of which can be sensitive, meaning that its confidentiality has to be protected. In this context, DIA providers are responsible for enforcing privacy policies that account for the privacy preferences of data subjects as well as for general privacy regulations. This is the case, for instance, of data brokers, i.e. companies that continuously collect and analyse data in order to provide useful analytics to their clients. Unfortunately, the enforcement of privacy policies in modern DIAs tends to become cumbersome because (i) the number of policies can easily explode, depending on the number of data subjects, (ii) policy enforcement has to autonomously adapt to the application context, thus, requiring some non-trivial runtime reasoning, and (iii) designing and developing modern DIAs is complex per se. For the above reasons, we need specific design and runtime methods enabling so called privacy-by-design in a Big Data context. In this article we propose an approach for specifying, enforcing and checking privacy policies on DIAs designed according to the Google Dataflow model and we show that the enforcement approach behaves correctly in the considered cases and introduces a performance overhead that is acceptable given the requirements of a typical DIA.\u3c/p\u3

Managing energy consumption as an architectural quality attribute

\u3cp\u3eA look at the software for an automated weather station shows that energy can be treated like any other architectural quality attribute. It's no different, from the perspective of architectural design, than modifiability, performance, or availability. It can be modeled and prototyped, and we can reason about the design tradeoffs required to achieve better energy use.\u3c/p\u3