Juan Julián Merelo

Building a monorepo composed of more than 25 modules, internal dependencies and iOS and Android app to boot is a challenge. Doing so fast and under a certain cost threshold might seem daunting. However, in polypoly we’ve tried to do it for the past few months, creating our own build/test tool with 0 dependencies and a straightforward approach to what a monorepo needs, when it needs.

Testing needs to follow the F.I.R.S.T. principles, of which the first one, Fast, is possibly the most important. Fast testing ensures that developers respond quickly to all kind of testing errors, and of course it keeps the cost of testing low.

Monorepos have additional challenges: dependencies cross language boundaries, dependence graphs are not explicit, and there's the risk of centralising some, none, or all the submodule upstream dependencies.

At polypoly we have been using a monorepo since May 2021. In this talk we will show how we have tackled this challenge with a series of GitHub actions, as well as creating a tool, build.js, which is geared towards dealing with monorepos.

We will show how this tool partially solves the speed issue, and what are our plans, going forward, to make tests faster and deal with implicit dependency graphs. We will also examine best practices in the area of monorepo builds for projects whose majority is written in Javascript/Typescript.

Metaprogramming is a technique that allows the creation of data and control structures during runtime. This gives adaptiveness and expressiveness to languages, allowing the creation of data structures with complex behavior, and adapted to the environment or to the data used. In this talk we will talk about general metaprogramming techniques, with examples in Raku and other modern languages.

Raku Steering Council Q&A panel is aimed at the audience interested in the Raku® programming language, its current state, and its future. Members of the Council will try to answer any related questions, including those about the Council itself.

GitHub has a nice environment for carrying out repository-event triggered workflows; these use a variety of runner platforms, including containers. This talk is about how to create a Raku container that can successfully act as a runner for workflows, and how to Rakuize the workflow API so that Raku scripts can interact meaningfully with this environment.

There are two parts on this talk; first, how to create a chain of increasingly complex Raku containers that can be used mainly for testing, and second, how to run some Raku scripts within those containers, with cool things that can be done inside those workflow using Raku.

Rakulang is great not only as a scripting language, but also at the conceptual level, allowing you to map problem-domain concepts to data structures easily. This comes handy when you use a specific kind of learning procedure that needs to track general class progress as well as individual attainment levels in a very precise way. In this context, we have created a Raku mini-library and a series of scripts that give us information on how a whole class of Cloud Computing students is progressing, and allows to pinpoint choke points, hurdles to progress, as well as individuals who might have been left behind.

We think that teaching software engineering should be just like software engineering, and in this context we have created a class with project-based learning, and objective-based learning. Students progress asynchronously through a series of objectives, with the student giving them individualized feedback on how to achieve those objectives. Objectives fulfillment is public, and this gives us a storage platform on which to build a series of scripts that show us the general degree of attainment by the class, as well as how every individual students are doing. These scripts are, for the time being, run manually. In the near future they will be integrated in a learning analytics workfow using GitHub actions, reducing the amount of manual running as much as possible. This, while not using a big amount of high-magic, shows how Raku expresiveness and whippipitude make the management of class extremely easy.

There are many things in which software can help grade computer science assignments, since these will consist mainly in executable pieces of code. However, in the same way DevOps will involve teams that code, test and set up infraestructure, ClassOps will have to add teachers to that equation. At any rate, it will imply that teachers will need to lay down in code the requirements of a student assignment (which can be as simple as testing for inclusion of a file or as complex of setting up the infrastructure to probe the code in different ways) and set up CI pipelines to actually test, and give meaningful (and fast!) feedback to the student so that it's included in their learning experience. This (lightning) talk will explain how the speaker set up that kind in infrastructure in Travis and, lately, GitHub actions, and how that resulted as a learning experience for him and his students.

For professors, grading is grunt work, and mostly done manually. As such, it's usually limited to the things that can be checked by hand. This eventually results in a very limited understanding of the learning process of students, lengthy grading process and bad learning outcomes for students. The first step is understanding grading as part of the learning process for students: it's simply a chance to give feedback to students so that they can fulfill their learning objectives. This needs to be done frequently and meaningfully. The second step is decoupling grading from your personal appreciation and setting it up as a functional requirement. Joining both things leads to automating grading as much as possible. While I had been using GitHub for turning in assignments for quite some time, I really started using CI pipelines in 2017, initially with Travis, and adding GitHub actions in 2019 when they started to admit people into the beta. They are used alongside each other now, making assignments undergo different kinds of tests, from (mild) plagiarism to, lately, setting up the student environment in a Docker container and run things inside it. The main idea of this talk will be how to pass from concept to (software) test, how the different tests have been set up, and what kind of obstacles have been found along the way. And, of course, if this has resulted in better learning outcomes for students.

Modern deployment workflows extensively employ CI/CD tools for tasks that go from simple testing to automating the creation of container images. Most of these machines have a version of Perl installed; in many cases because it's an essential language used for many tools in the operating system it runs, in some other cases simply because it's there. In most cases, though, its existence is undocumented. In this talk we will make a small introduction to Perl and how it's relevant to 21st century computing, and then we'll show how to put it to good use in environments such as Travis, Github Actions and even Docker Hub.

I've been using Perl for more than 25 years, and in fact I started using Travis because it was the only CI/CD tool back then that gave good support to this language. However, over the years I have seen how new tools stopped mentioning it for other languages, notably JavaScript. This meant that, when I needed to write new workflows on base environments, I needed to use shell script and other tools like awk and sed. Which are wonderful tools, but it's almost impossible to be really productive with them. Out of curiosity mainly, I started running uname -v and perl --version over the machines where I was bumping my head against shell scripts, and lo and behold, I discovered that, undocumented, Perl was there. That started a quest for creating pull requests all over the place so that its presence is documented... And also a series of initiatives to actually put it down to use.

Baseline is: since Perl is already present in the environments used to run workflows, you can save precious seconds of language installation, and you can actually perform some serious data munging and processing using the base configuration. We will show different examples of this in different environments, and also some ways to speed up even more your workflows to save those precious seconds that are in such short supply in the free tier lately.

Raku is a multi-paradigm language, that is able to do meta-programming, declarative, object-oriented programing as well as many other specific features. At 5 years, it's still a young language, but some patterns are emerging that make it quite suitable for practicing your programming chops, or embark in some side project. In this talk we will introduce some interesting programming patterns that are seen, possibly, nowhere else, from "grammaroles" through "piggybacking objects". On the other hand, for a language where TIMTOWDI, there is more than one way to do it, talking about antipatterns might look paradoxical. So let's see how we get out of this catch-22 situation.

Raku was created as a language for the next 100 years by its creator, Larry Wall, and as such it incorporates most of the paradigms tha modern language use, from a very extensive Unicode foundation, to a more classic, but still new at heart, approach to functional programming. It's this mix and match of programming paradigms that make it unique, and it's also what has provoked the emergence of certain programming patterns that solve unique problems in an interesting way. This arises as much from its design, as from its implementation, which uses Raku itself for most of it. Anyway, this talk will be about a short introduction to some Raku features, followed by a few programming patterns exemplified in Raku and in the closest you can get in other, modern languages. The main objective of the talk is to pique the curiosity about this language, which is still new, and its interesting, diverse and enthusiastic community.

A brief introduction to the 2021 virtual FOSDEM devroom, talk overview, code of conduct and Community Affairs Team.

Please ask any questions after the introduction - there will be 10 minutes for discussion.

TPF Code of Conduct applies to our devroom

Most languages steadily incorporate new programming concepts in new releases, and new languages have these concepts already baked in. These concepts are related to how functions work and are considered and invoked, different data structures and working with things like Unicode. There's a language, Raku, that incorporates most of the new concepts that have appeared in this century. This talk is an introduction to the language by way of the concepts it uses.

Known as Perl 6 until October 14th this year, and released in Christmas 2015, Raku (https://raku.org) was designed as "The language for the next 100 years", and as such, it was created with the intention of incorporating most modern programming concepts. With the same motto as its (kind-of) predecessor, Perl, "There are many ways to do it", Raku is a multi-paradigm language that is functional, asynchronous, object-oriented, and with new interesting features like grammars. In this talk I'll take a look at a dozen of features of modern languages; I'll exemplify every feature with examples from different languages, trying to get through the different concepts of Raku by way of how they are implemented in other languages. Finally, we'll see a few examples of Raku, showing how its rich feature set makes it ideal for learning new programming concepts, as well as putting them to good use to solve your own problems.

"Although I have been using GitHub for assignment submission for a long time, it has been only this year, when after being fired from the Free Software Office of the university of Granada I lost the class assistant, when I felt the dire need to do some automatic checks on the assignments the students of a cloud computing class turned it. This was not only running some tests on the code; since the students have total freedom on the language and other aspects of their project, it had to check things that went from the presence of some files to the use of GitHub issues for organization of the tasks. This was eventually solved with a Perl script that tested every pull request made by students. And this has had a number of interesting and mostly positive side effects on the student behavior and performance, which will be examined and presented in this presentation, where I will do no theater and dress with a single tee. Promised. Take home message is one that I have trying to drive home since the beginning, when I was talking about how Perl saved a conference I was organizing: Perl is an incredible tool for automating simple tasks that nobody thought could actually be automated; and automating things has many implications for the automator and the automatees; so Perl and daily life are always interesting and winning combinations.

Book production, from inception to publication, is still very much trapped in writing-correction-production cycles that resemble how software was made much earlier. However, productivity would be very much increased if the writing-correction-publication would be taken a step (or two forward) to a continuous integration/continuous delivery DevOps-like environment where you define by software the whole pipeline a book is going to follow from writing to publication. LitOps is a transpiling of the DevOps culture to book production, using mainly software development tools, and rigging them so that you can produce and publish quality-checked books using as many automation tools as possible.

Although most arts make extensive use of automation tools, from textures in comic to automatic motion generation tools in 2 or 3-d animation, writing a book, whatever its class, technical or fiction, gives the word manuscript its full meaning, since the most advanced tool used is the spell and maybe grammar checker. This leads to long development cycles, with new editions published after long rewriting-edition-production cycles. Nowadays, authors can publish directly using a variety of places, from Leanpub to Kindle Direct Publishing, and there are all kind of tools available for doing that kind of thing. Still, this has not lead to fast production cycles where new editions are produced as soon as "bugs" are found and fixed and all formats are published at the same time. My personal history in this area started when I decided to write a book from the first line using GitHub. That lead to using continuous integration, and it kind of ballooned from here. Nowadays I have created a full automation suite, in Perl6 and Python, that produces "printed" versions (shortening and expanding URLs), checks for line bleeds, and produces several high-quality formats from a Markdown source; time from change to new publication-ready version takes a few seconds. The only thing missing is an API for publication sites that would allow to make an automatic deployment. However, even without that final steps, the LitOps concept that codifies book production pipelines using scripts, including error checks and the rest, actually might mean a sea change in how fiction and non-fiction is produced, using LitOps teams and adopting the rest of the patterns of the software industry: forking, hackathons and linting, and finally taking manuscripting to this century.

With DOM, software-defined architecture, advanced build tools, StackOverflow and ultra-high-level languages, main languages are still taught (and learned) via I/O operations, simple data structures, loops and switches, and little space to development and deployment environment advances and even algorithmic changes, like asynchronous running, that completely upend the way programming language, and programming, concepts should be assimilated. In this presentation I'd like to advocate for a multi-lingual, multi-paradigm, multi-tool approach to learning programming languages and how this could eventually be carried out.

The new century has seen an explosion of new ways of learning: through MOOCs, Webinars, bootcamps and incorporation of new technologies to learning. Still, syllabus of programming languages pretty much stays the same. There is enphasis in learning a single language (front end, back end, DSL) and a progress that goes from very simple input/output operations through some simple data structures to loops and other programming structures. This works usually well and the proof is all around us; besides, the ten first programming languages are the hardest, it is downhill from there. However, it could be much easier if we acknowledged the existence of this multi-environment (console, UI, web, embedded), multi-language (many languages in a single application, from data description to UI language), multi-tool (from simple compilation tools to deployment and monitoring tools) and organized our learning experience around it. And first we should use whatever we have on hand, like command-line interfaces (some of them with powerful languages) or even the browser itself, which always include a programmer mode. Also use visual languages like Scratch to teach more complicated concepts, as long as they are put into use with languages that can run the whole nine yards. In this lightning talk I will try to outline what would be the first basic steps in a course following these principles, and why I think this would lead to faster formation of programmers and the creation of a more adaptive mindset when tackling new careers or project in programming.

The best metaphor for Perl is and has been an onion.

However, when we're teaching seminars or writing books, we mostly focus on one or two onion layers; those that concern syntax and grammar. Learning to program, learning to create applications, is so much more than focusing on how to get the syntax checker to not bail out when we put characters together, it's about creating efficient, effective and pretty applications that last and can continue development later on. So we have to change the way we teach Perl (and for that matter, every single language and stack in the world). I'll focus on what I think we should do, but we'll first have to see what we do (wrong) and how to do it right.

We live in an age in which every person owns two or three devices that are powerful enough to render a few seconds of 3D movies in a while although they are used mainly to send messages via WhatsApp and create selfies for social network consumption. At the same time, all these devices have the closest thing to an universal virtual machine that has ever existed: the JavaScript virtual machined, paired to a (roughly) standard object model that allows anybody with a bit of programming prowess to create programs that can be run anywhere and everywhere. There is great potential for massive distributed computing in this environment, but the ability to tap it a bit farther than sending basic computations is not there yet. In this presentation we will talk about the issues involved in doing so, from basic algorithmic issues to twisted legal issues that can arise when you are using devices you don't own to perform unwitting computations.

Volunteer computing was started thanks to lack of funds and surplus of computing power (and connectivity to go with it) on the hands of labs and companies. Stealth computing was proposed initially by Barabasi to take advantage of devices connected to the network that perform very basic computations. There's a very fine line between them, a line that includes a button that says "Click here" or the will to not use resources more than those dutifully allotted by the operating system. There are also usability differences between volunteer and stealth computing and maybe ethical and legal ones. However, from the point of view of the computing model and the techniques involved, there is no difference. In this talk we will explore the possibilities of stealth/volunteer computing using mainly the browser and the issues involved with it. The main one is performance, either from the algorithmic point of view or CPU-cycles-wise. How many CPU cycles could be achievable using them? Is it predictable in a way? And there is an intriguing edge to the performance model: it includes the fact that there will be a big dependence on the web page that is used itself, from its content, to its search engine position, to the way it is announced in social networks and by whom. Even as there is some predictability in the whole experiment, from the algorithmic point of view it is impossible to know, in advance, how long a particular user is going to stay contributing to the system and when he's going to come and go. This is an issue that has to be leveraged in the algorithm so that these cycles contributed actually add something to the whole experiment and do not detract from it. We will specially talk about population-based algorithms, which are the ones we do have a certain experience with, but any algorithm that has some dependencies (that is, anything that goes beyond brute-force approach) will experience similar issues. Finally, there are some trust issues that must also be taken into account. There are purely legal issues, but stealthy volunteer (or voluntarily stealth) computing should follow open science best practices, since that is the only way of managing a healthy and sustainable meta-computing device where people or citizens have a huge role.

In this talk, we will present the state of the art and history of volunteer and, in particular, browser-based computing, will make a general introduction to evolutionary computation, and then how this type of algorithms can be adapted to run on ephemeral, distributed, asynchronous, and heterogeneous nodes. We will present our NodEO and jsEO evolutionary algorithm libraries and the result of some experiments using this platform. Finally, we will generalize and show a general methodology for doing scientific computing using JavaScript.

Do you need Perl to write a novel? Indeed you don't and many, if not most, novelists write them without using it, and I'm positive about this. However, Perl can help you through the process of writing a novel and that's what I've done with the open source "Manuel the Magnificent Mechanical Man", which you can either buy in Amazon or download as a CPAN module. I'll talk about how I organized the workflow for writing the novel using Perl, Git, GitHub, and the modules and Perl features which helped me through the process.

In this venue I don't think it is necessary to talk about the advantages of open source in science. So let me add another one: it is incredibly easy to set up an almost free volunteer computing infrastructure which you can then use for crowdsourced experiments. In fact, SETI@home, the quintessentially crowdsourcing environment, has been released as the libre BOINC platform; but nowadays, with just a few lines of code and a plain vanilla server, you can create your own volunteer (or not-so) computing environment. In this talk we will explain how to set up a browser-based volunteer computing platform using NoSQL servers and what are the advantages of doing so (including a boost to your H number).

Universities are the source of huge amounts of lines of code and also of graduates that, later on, will be the ones writing code. It's essential that, as soon as they are exposed to the act of creating software, they also are explained that software can be free (and, in fact, it can be argued that it should be free) and that they, themselves, can make it free. Not only that: university staff and professors and researchers have to be given the opportunity to adopt the libre software philosophy in their use, acquisition and development of software.

Evolutionary algorithms are optimization methods used throughout a wide array of problems, from industrial operations through games to bioinformatics. Its key operations are done on strings and arrays, and given the nature of scientific work, it pays to be code-productive more than high performance. However, high performance pays too, so in this talk we will introduce several Perl evolutionary algorithm modules and how they have been applied to several problems and improved using profiling.