Many of the tools we develop build depend on core numerical libraries such as FFTW, or more generally ecosystems such as those from netlib or scipy. Whilst in many cases these core libraries are well regarded and used, the need to either run tools in new environments (such as client-side in a web browser or on a mobile device), or with the rise of new challengers to the current Fortran/C/C++ ecosystem, such as Rust, Julia or possibly even Go, means that either these libraries are being ported, or new libraries being written wholesale. This BoF aims to start the conversation around what we can do to ensure these new libraries are trustworthy, by firstly covering some of the experience of the BoF organisers, and then opening up a wider discussion.

The Astrophysics Source Code Library contains over 2700 metadata records on astro researchsoftware. This short hands-on tutorial is geared to new users of the resource, though evenadvanced users of it are sure to learn something new.Attendees will learn:* alternate ways to bring up ASCL records* how to find software * Hands-on activity: Search for software using at least three different methods: * full-text search * ASCL’s API * ADS and Google* how citation tracking and preferred citation work* how to create a metadata file for their own software that tells others how to cite their code * Hands-on activity: Create codemeta.json and CITATION.cff files using ASCL and GitHub * Hands-on activity: Add preferred citation information to their own software* what metadata is contained in the ASCL and how it is structured* how to download the ASCL’s contents for their own projects * Hands-on activity: Experiment with ASCL metadata using some simple tools* how to submit software to the ASCL * Optional hands-on activity: Submit a code to the ASCLThe tutorial will cover related topics, including the differences between ASCL and ZENODO, andhow, why, and when to submit to each, as time permits.

The Julia programming language can be considered the successor to Scientific Python (SciPy). The language is designed for scientific computing by having built-in multi-dimensional arrays and parallel processing features. Yet, it can also be used as a general-purpose programming language like Python. Unlike Python, Julia solves the two-language problem by using just-in-time (JIT) compilation to generate machine code from high level expressions. In most cases, Julia is as fast as C, and in some cases faster. Julia is also a composable language, so independent libraries or packages usually work well together without any modification. These important features make Julia a very productive language for scientific software development by reducing the number of lines of code.

Software testing, in all its forms, is a crucial part of the software development process. It can take a significant fraction of time and effort but its perceived importance (and therefore allocated funding) is often minimal in all but very large projects. Automated CI/CD systems, for example, are a useful set of tools to streamline and automate some of this important task, increasing testing coverage and confidence in our product, and in turn freeing developers to do more creative work. Nevertheless, as developers we often still find ourselves doing more donkey work in this space than we would prefer, or - worse - decreasing the amount of testing to meet a deadline or create the illusion of decreasing project cost.This BoF will discuss how we test our software: what works, what doesn’t for small and large projects, and how we can use our experiences to help each other to both improve testing and minimise the effort required to test well. We will encourage participants to pose questions, offer suggestions, and even air dirty laundry in a judgement-free space.

ESAC Science Data Centre (ESDC) hosts ESA archives for Astronomy, Planetary and Heliophysics Space Science. Built around science-return as its central pillar, ESA Datalabs aims to present itself to the end-user as an intuitive system for swift access to a large catalogue of data volumes and processing tools effectively integrated in a single platform. Behind this glossy curtain, hidden from the user, lays an IT infrastructure which features an extremely sophisticated architectural blueprint. Kubernetes clusters, Rancher, ElasticSearch engines, Docker containers, and many other usual suspects of the High-Performance Computing world, team-up to deliver an innovative experience. This focus demo will guide the audience through multiple catalogues that shape the application store and software as service concepts present in ESA Datalabs.

The sample of Solar system objects has dramatically increased over the last decades. The amount of measured properties has grown even faster. The benefit of all these developments has, however, not come to full fruition. While some catalogs are publicly available in machine-readable formats, a significant fraction of results are only tabulated within articles. Furthermore, the designation of small bodies often evolves with time, from potentially several provisional designations, to a single number and finally an official name. Hence, the same object can be referred to by different labels in different studies, making its cross-identification over several sources a complex task. A universal access point for all measured properties of Solar system objects available in the literature and online databases is thus required.We provide a practical solution to the identification of Solar system objects from any of their multiple name/designation. We built a Web Service, SsODNet, that offers four interfaces, each corresponding to an identified typical need in the community: name resolution (quaero), compilation of a large corpus of properties (datacloud), determination of the best estimates among compiled values (ssoCard), and statistical description of the population (BFT).

A new generation of survey telescopes with large etendues (the product of field of view andcollecting area), are detecting and resporting variable astrophysical events in the form of largeastronomical alert streams. In particular, the Zwicky Transient Facility has been producingapproximately 300 k alerts per night since 2018 and the Vera C. Rubin Observatory will produceabout 10 M alerts per night since 2024. In order to make sense of these large alert streams anew type of system is needed: the astronomical alert brokers. Several brokers have beenprocessing the alert stream from ZTF, and seven brokers have been selected as CommunityBrokers for the Vera C. Rubin Observatory and its Legacy Survey of Space and Time (LSST):ALeRCE, ANTARES, AMPEL, Babamul, Fink, Lasair and Pitt-Google. These brokers willbecome intermediaries between survey telescopes and follow-up resources and will offerdifferent services for the general community to provide access to the alert stream and enablethe best science from these data. In this tutorial we will present the tools and services providedby the ALeRCE broker.