Feeds

A variant of the yield statement that can result in more concise code.

Let’s go for last web review of 2024!

This is Your Brain On Surveillance: New Study Reveals How Awareness of Being Watched Alters Our Brains - The Debrief

Tags: tech, surveillance, psychology, cognition

It looks like it’s not only impacting negatively our privacy. The linked paper (good to read as well) hints at negative impacts on mental health as well. Still needs to be fully validated but it doesn’t look good already.

https://thedebrief.org/this-is-your-brain-on-surveillance-new-study-reveals-how-awareness-of-being-watched-alters-our-brains/

The era of open voice assistants has arrived - Home Assistant

Tags: tech, smarthome, foss

Nice move from the home assistant people. Such open and privacy respecting hardware is needed.

https://www.home-assistant.io/blog/2024/12/19/voice-preview-edition-the-era-of-open-voice/

The Ghosts in the Machine, by Liz Pelly

Tags: tech, music, copyright

You love artists and their music? You probably should get off Spotify then… because they’re clearly at war to reduce even further how much they pay artists. Clearly it’s not about discovering artists anymore, it’s about pumping cheap stock music to increase their margin. Also its clear the remaining musicians trapped in that system will be automated away soon… you don’t need humans to create soulless music.

https://harpers.org/archive/2025/01/the-ghosts-in-the-machine-liz-pelly-spotify-musicians/

My colleague Julius

Tags: tech, ai, machine-learning, gpt, criticism, knowledge

OK, this is a nice parabole. I admit I enjoyed it.

https://ploum.net/2024-12-23-julius-en.html

Can AI do maths yet? Thoughts from a mathematician

Tags: tech, ai, machine-learning, gpt, mathematics

Looks like we’re still a long way from mathematical accuracy with the current generation of models. It made progress of course.

https://xenaproject.wordpress.com/2024/12/22/can-ai-do-maths-yet-thoughts-from-a-mathematician/

Lua is so underrated

Tags: tech, programming, language, lua

It’s a not niche indeed but has its place in some applications.

https://nflatrea.bearblog.dev/lua-is-so-underrated/

Simpler and faster parsing code with std::views::split – Daniel Lemire’s blog

Tags: tech, c++, performance

A good reason to use more modern C++20 APIs for parsing code.

https://lemire.me/blog/2024/12/21/simpler-and-faster-parsing-code-with-stdviewssplit/

A Simple ELF

Tags: tech, unix, elf, system

Nice little introduction to the ELF format.

https://4zm.org/2024/12/25/a-simple-elf.html

Electronics Test Gear on the Cheap

Tags: tech, electronics

Price of such gear definitely went down indeed.

https://bigdanzblog.wordpress.com/2024/12/25/electronics-test-gear-on-the-cheap/

Server-Sent Events (SSE) Are Underrated

Tags: tech, web, http

This is definitely an overlooked alternative to websockets. It doesn’t apply everywhere of course but when it does it’s a good pick.

https://igorstechnoclub.com/server-sent-events-sse-are-underrated/

On Long Term Software Development - Bert Hubert’s writings

Tags: tech, engineering, supply-chain, complexity, dependencies, maintenance

There is some good advice in this piece. If you want to maintain something for a long time, some aspects need to be thought out from the beginning.

https://berthub.eu/articles/posts/on-long-term-software-development/

Problem Driven Development | Stay SaaSy

Tags: tech, project-management, product-management, engineering, quality

Struggling with making your first technical roadmap? Driving it from measurable problems is a good first step.

https://staysaasy.com/engineering/2024/12/17/problem-driven-development.html

The number pi has an evil twin… - Mathstodon

Tags: mathematics

Interesting thread. I didn’t know about this family of constants. Fun stuff.

https://mathstodon.xyz/@johncarlosbaez/113703444230936435

Bye for now!

At work, I've been maintaining a perl script that needs to run a number of steps as part of a release workflow.

Initially, that script was very simple, but over time it has grown to do a number of things. And then some of those things did not need to be run all the time. And then we wanted to do this one exceptional thing for this one case. And so on; eventually the script became a big mess of configuration options and unreadable flow, and so I decided that I wanted it to be more configurable. I sat down and spent some time on this, and eventually came up with what I now realize is a domain-specific language (DSL) in JSON, implemented by creating objects in Moose, extensible by writing more object classes.

Let me explain how it works.

In order to explain, however, I need to explain some perl and Moose basics first. If you already know all that, you can safely skip ahead past the "Preliminaries" section that's next.

Preliminaries Moose object creation, references.

In Moose, creating a class is done something like this:

package Foo; use v5.40; use Moose; has 'attribute' => ( is => 'ro', isa => 'Str', required => 1 ); sub say_something { my $self = shift; say "Hello there, our attribute is " . $self->attribute; }

The above is a class that has a single attribute called attribute. To create an object, you use the Moose constructor on the class, and pass it the attributes you want:

use v5.40; use Foo; my $foo = Foo->new(attribute => "foo"); $foo->say_something;

(output: Hello there, our attribute is foo)

This creates a new object with the attribute attribute set to bar. The attribute accessor is a method generated by Moose, which functions both as a getter and a setter (though in this particular case we made the attribute "ro", meaning read-only, so while it can be set at object creation time it cannot be changed by the setter anymore). So yay, an object.

And it has methods, things that we set ourselves. Basic OO, all that.

One of the peculiarities of perl is its concept of "lists". Not to be confused with the lists of python -- a concept that is called "arrays" in perl and is somewhat different -- in perl, lists are enumerations of values. They can be used as initializers for arrays or hashes, and they are used as arguments to subroutines. Lists cannot be nested; whenever a hash or array is passed in a list, the list is "flattened", that is, it becomes one big list.

This means that the below script is functionally equivalent to the above script that uses our "Foo" object:

use v5.40; use Foo; my %args; $args{attribute} = "foo"; my $foo = Foo->new(%args); $foo->say_something;

(output: Hello there, our attribute is foo)

This creates a hash %args wherein we set the attributes that we want to pass to our constructor. We set one attribute in %args, the one called attribute, and then use %args and rely on list flattening to create the object with the same attribute set (list flattening turns a hash into a list of key-value pairs).

Perl also has a concept of "references". These are scalar values that point to other values; the other value can be a hash, a list, or another scalar. There is syntax to create a non-scalar value at assignment time, called anonymous references, which is useful when one wants to remember non-scoped values. By default, references are not flattened, and this is what allows you to create multidimensional values in perl; however, it is possible to request list flattening by dereferencing the reference. The below example, again functionally equivalent to the previous two examples, demonstrates this:

use v5.40; use Foo; my $args = {}; $args->{attribute} = "foo"; my $foo = Foo->new(%$args); $foo->say_something;

(output: Hello there, our attribute is foo)

This creates a scalar $args, which is a reference to an anonymous hash. Then, we set the key attribute of that anonymous hash to bar (note the use arrow operator here, which is used to indicate that we want to dereference a reference to a hash), and create the object using that reference, requesting hash dereferencing and flattening by using a double sigil, %$.

As a side note, objects in perl are references too, hence the fact that we have to use the dereferencing arrow to access the attributes and methods of Moose objects.

Moose attributes don't have to be strings or even simple scalars. They can also be references to hashes or arrays, or even other objects:

package Bar; use v5.40; use Moose; extends 'Foo'; has 'hash_attribute' => ( is => 'ro', isa => 'HashRef[Str]', predicate => 'has_hash_attribute', ); has 'object_attribute' => ( is => 'ro', isa => 'Foo', predicate => 'has_object_attribute', ); sub say_something { my $self = shift; if($self->has_object_attribute) { $self->object_attribute->say_something; } $self->SUPER::say_something unless $self->has_hash_attribute; say "We have a hash attribute!" }

This creates a subclass of Foo called Bar that has a hash attribute called hash_attribute, and an object attribute called object_attribute. Both of them are references; one to a hash, the other to an object. The hash ref is further limited in that it requires that each value in the hash must be a string (this is optional but can occasionally be useful), and the object ref in that it must refer to an object of the class Foo, or any of its subclasses.

The predicates used here are extra subroutines that Moose provides if you ask for them, and which allow you to see if an object's attribute has a value or not.

The example script would use an object like this:

use v5.40; use Bar; my $foo = Foo->new(attribute => "foo"); my $bar = Bar->new(object_attribute => $foo, attribute => "bar"); $bar->say_something;

(output: Hello there, our attribute is foo)

This example also shows object inheritance, and methods implemented in child classes.

Okay, that's it for perl and Moose basics. On to...

Moose Coercion

Moose has a concept of "value coercion". Value coercion allows you to tell Moose that if it sees one thing but expects another, it should convert is using a passed subroutine before assigning the value.

That sounds a bit dense without example, so let me show you how it works. Reimaginging the Bar package, we could use coercion to eliminate one object creation step from the creation of a Bar object:

package "Bar"; use v5.40; use Moose; use Moose::Util::TypeConstraints; extends "Foo"; coerce "Foo", from "HashRef", via { Foo->new(%$_) }; has 'hash_attribute' => ( is => 'ro', isa => 'HashRef', predicate => 'has_hash_attribute', ); has 'object_attribute' => ( is => 'ro', isa => 'Foo', coerce => 1, predicate => 'has_object_attribute', ); sub say_something { my $self = shift; if($self->has_object_attribute) { $self->object_attribute->say_something; } $self->SUPER::say_something unless $self->has_hash_attribute; say "We have a hash attribute!" }

Okay, let's unpack that a bit.

First, we add the Moose::Util::TypeConstraints module to our package. This is required to declare coercions.

Then, we declare a coercion to tell Moose how to convert a HashRef to a Foo object: by using the Foo constructor on a flattened list created from the hashref that it is given.

Then, we update the definition of the object_attribute to say that it should use coercions. This is not the default, because going through the list of coercions to find the right one has a performance penalty, so if the coercion is not requested then we do not do it.

This allows us to simplify declarations. With the updated Bar class, we can simplify our example script to this:

use v5.40; use Bar; my $bar = Bar->new(attribute => "bar", object_attribute => { attribute => "foo" }); $bar->say_something

(output: Hello there, our attribute is foo)

Here, the coercion kicks in because the value object_attribute, which is supposed to be an object of class Foo, is instead a hash ref. Without the coercion, this would produce an error message saying that the type of the object_attribute attribute is not a Foo object. With the coercion, however, the value that we pass to object_attribute is passed to a Foo constructor using list flattening, and then the resulting Foo object is assigned to the object_attribute attribute.

Coercion works for more complicated things, too; for instance, you can use coercion to coerce an array of hashes into an array of objects, by creating a subtype first:

package MyCoercions; use v5.40; use Moose; use Moose::Util::TypeConstraints; use Foo; subtype "ArrayOfFoo", as "ArrayRef[Foo]"; subtype "ArrayOfHashes", as "ArrayRef[HashRef]"; coerce "ArrayOfFoo", from "ArrayOfHashes", via { [ map { Foo->create(%$_) } @{$_} ] };

Ick. That's a bit more complex.

What happens here is that we use the map function to iterate over a list of values.

The given list of values is @{$_}, which is perl for "dereference the default value as an array reference, and flatten the list of values in that array reference".

So the ArrayRef of HashRefs is dereferenced and flattened, and each HashRef in the ArrayRef is passed to the map function.

The map function then takes each hash ref in turn and passes it to the block of code that it is also given. In this case, that block is { Foo->create(%$_) }. In other words, we invoke the create factory method with the flattened hashref as an argument. This returns an object of the correct implementation (assuming our hash ref has a type attribute set), and with all attributes of their object set to the correct value. That value is then returned from the block (this could be made more explicit with a return call, but that is optional, perl defaults a return value to the rvalue of the last expression in a block).

The map function then returns a list of all the created objects, which we capture in an anonymous array ref (the [] square brackets), i.e., an ArrayRef of Foo object, passing the Moose requirement of ArrayRef[Foo].

Usually, I tend to put my coercions in a special-purpose package. Although it is not strictly required by Moose, I find that it is useful to do this, because Moose does not allow a coercion to be defined if a coercion for the same type had already been done in a different package. And while it is theoretically possible to make sure you only ever declare a coercion once in your entire codebase, I find that doing so is easier to remember if you put all your coercions in a specific package.

Okay, now you understand Moose object coercion! On to...

Dynamic module loading

Perl allows loading modules at runtime. In the most simple case, you just use require inside a stringy eval:

my $module = "Foo"; eval "require $module";

This loads "Foo" at runtime. Obviously, the $module string could be a computed value, it does not have to be hardcoded.

There are some obvious downsides to doing things this way, mostly in the fact that a computed value can basically be anything and so without proper checks this can quickly become an arbitrary code vulnerability. As such, there are a number of distributions on CPAN to help you with the low-level stuff of figuring out what the possible modules are, and how to load them.

For the purposes of my script, I used Module::Pluggable. Its API is fairly simple and straightforward:

package Foo; use v5.40; use Moose; use Module::Pluggable require => 1; has 'attribute' => ( is => 'ro', isa => 'Str', ); has 'type' => ( is => 'ro', isa => 'Str', required => 1, ); sub handles_type { return 0; } sub create { my $class = shift; my %data = @_; foreach my $impl($class->plugins) { if($impl->can("handles_type") && $impl->handles_type($data{type})) { return $impl->new(%data); } } die "could not find a plugin for type " . $data{type}; } sub say_something { my $self = shift; say "Hello there, I am a " . $self->type; }

The new concept here is the plugins class method, which is added by Module::Pluggable, and which searches perl's library paths for all modules that are in our namespace. The namespace is configurable, but by default it is the name of our module; so in the above example, if there were a package "Foo::Bar" which

• has a subroutine handles_type
• that returns a truthy value when passed the value of the type key in a hash that is passed to the create subroutine,
• then the create subroutine creates a new object with the passed key/value pairs used as attribute initializers.

Let's implement a Foo::Bar package:

package Foo::Bar; use v5.40; use Moose; extends 'Foo'; has 'type' => ( is => 'ro', isa => 'Str', required => 1, ); has 'serves_drinks' => ( is => 'ro', isa => 'Bool', default => 0, ); sub handles_type { my $class = shift; my $type = shift; return $type eq "bar"; } sub say_something { my $self = shift; $self->SUPER::say_something; say "I serve drinks!" if $self->serves_drinks; }

We can now indirectly use the Foo::Bar package in our script:

use v5.40; use Foo; my $obj = Foo->create(type => bar, serves_drinks => 1); $obj->say_something;

output:

Hello there, I am a bar. I serve drinks!

Okay, now you understand all the bits and pieces that are needed to understand how I created the DSL engine. On to...

Putting it all together

We're actually quite close already. The create factory method in the last version of our Foo package allows us to decide at run time which module to instantiate an object of, and to load that module at run time. We can use coercion and list flattening to turn a reference to a hash into an object of the correct type.

We haven't looked yet at how to turn a JSON data structure into a hash, but that bit is actually ridiculously trivial:

use JSON::MaybeXS; my $data = decode_json($json_string);

Tada, now $data is a reference to a deserialized version of the JSON string: if the JSON string contained an object, $data is a hashref; if the JSON string contained an array, $data is an arrayref, etc.

So, in other words, to create an extensible JSON-based DSL that is implemented by Moose objects, all we need to do is create a system that

• takes hash refs to set arguments

• has factory methods to create objects, which

  • uses Module::Pluggable to find the available object classes, and
  • uses the type attribute to figure out which object class to use to create the object

• uses coercion to convert hash refs into objects using these factory methods

In practice, we could have a JSON file with the following structure:

{ "description": "do stuff", "actions": [ { "type": "bar", "serves_drinks": true, }, { "type": "bar", "serves_drinks": false, } ] }

... and then we could have a Moose object definition like this:

package MyDSL; use v5.40; use Moose; use MyCoercions; has "description" => ( is => 'ro', isa => 'Str', ); has 'actions' => ( is => 'ro', isa => 'ArrayOfFoo' coerce => 1, required => 1, ); sub say_something { say "Hello there, I am described as " . $self->description . " and I am performing my actions: "; foreach my $action(@{$self->actions}) { $action->say_something; } }

Now, we can write a script that loads this JSON file and create a new object using the flattened arguments:

use v5.40; use MyDSL; use JSON::MaybeXS; my $input_file_name = shift; my $args = do { local $/ = undef; open my $input_fh, "<", $input_file_name or die "could not open file"; <$input_fh>; }; $args = decode_json($args); my $dsl = MyDSL->new(%$args); $dsl->say_something

Output:

Hello there, I am described as do stuff and I am performing my actions: Hello there, I am a bar I am serving drinks! Hello there, I am a bar

In some more detail, this will:

• Read the JSON file and deserialize it;
• Pass the object keys in the JSON file as arguments to a constructor of the MyDSL class;
• The MyDSL class then uses those arguments to set its attributes, using Moose coercion to convert the "actions" array of hashes into an array of Foo::Bar objects.
• Perform the say_something method on the MyDSL object

Once this is written, extending the scheme to also support a "quux" type simply requires writing a Foo::Quux class, making sure it has a method handles_type that returns a truthy value when called with quux as the argument, and installing it into the perl library path. This is rather easy to do.

It can even be extended deeper, too; if the quux type requires a list of arguments rather than just a single argument, it could itself also have an array attribute with relevant coercions. These coercions could then be used to convert the list of arguments into an array of objects of the correct type, using the same schema as above.

The actual DSL is of course somewhat more complex, and also actually does something useful, in contrast to the DSL that we define here which just says things.

Creating an object that actually performs some action when required is left as an exercise to the reader.

As in 2023 I took another look back at what changed in Phosh in 2024 and instead of just updating my notes why not again share it here. The Phosh developers focus from day one was to make devices running Phosh daily drivable without having to resort to any proprietary OSes as a fallback. So the past years were often dominated by adding essential features to make that possible and reliable at all.

This blog post will guide you through the entire process of preparing your Qt for Android app with CMake for publishing on the Play Store. By the end, you’ll be ready to distribute your Qt app to millions of Android users, buckle up! 

Like every year I take a couple of days off at the end of the year to wind down and spent time with the family. The year has brought many major changes, both to KDE and to me personally: We did the KDE MegaRelease 6, the next major update to KDE’s software suite. Plasma 6 further made Wayland the default graphical session. I also spent a lot more time in Qt itself, particularly Qt Wayland, rather than KDE code. Anyhow, between family visits and feasts there’s always some time for quality KDE hacking.

That’s right: Monitoring task progress in Konsole while busy doing something else

I’ve always been a huge fan of Windows 7’s task bar with its progress reporting and Jump Lists. Nine years ago (wow, really?!) I added support for the Unity Launcher API to Plasma’s task bar in order to display download and copy progress. The other day I was browsing systemd changelog when I stumbled upon:

The various components that display progress bars […], will
now also issue the ANSI sequences for progress reports that Windows Terminal understands. Most Linux terminals currently do not support this sequence (and ignore it), but hopefully this will change one day.

I hope so, too! Guess whose Konsole understands ConEmu-specific OSC (Operating System Command), the stuff systemd uses, for progress reporting now? There’s still a few quirks to be worked out since Konsole allows you to have multiple split views within the same tab. Nevertheless, we’ve got plenty of time until the next KDE Gear release in April 2025 to finalize it. Moreover, I asked kde-builder (KDE’s meta build system and spiritual successor to kdesrc-build) to support it, so you could monitor KDE compile progress at a glance.

I’m a scratch-your-own-itch type of guy. When I finally got fed up with Element (a Matrix chat client) in a browser window eating my CPU, I gave our own NeoChat application a try. The first thing I added was a “Copy Link Address” context menu when hovering a link in addition to fixing the missing “Edit” entry. Next, I had the window title include the chat room name since that’s what I am usually looking for in my task bar. Finally, Kirigami’s Avatar component can now load its image asynchronously which should speed up scrolling through the timeline and lists of rooms and users.

Ink marker colors shown again in redesigned Printer Manager

Speaking of Kirigami, Qt 6.8 added an animateClick function to buttons. It briefly flashes and then triggers it. This is now used throughout Kirigami in keyboard shortcut handling, bringing it in line with the Qt Widget world. Qt 6, too, has a concept of “accent color” for a few releases. Plasma’s accent color system predates it, though, so there’s some friction between the two. While we don’t have a proper Kirigami Theme API for it yet, at least setting the highlight now also sets the accent color. With that, ink cartridge levels have the appropriate marker colors in printer settings again. Speaking of accent color, I just backported some changes we made for Frameworks 6 to Frameworks 5 to ensure that KF5 apps can interpret Breeze Icons from KF6 properly, notably fixing the black folder icons.

I hope you also got the chance to spend some time with your loved ones. If you enjoyed what the KDE Community brought you this year, please consider donating to our Year End Fundraiser or to me personally, so we can continue rocking in 2025!

Discuss this post on KDE Discuss.

pastewindow is a neovim plugin written in Lua to help to paste text from a buffer to a different window in Neovim. This is my first attempt of writing a plugin.

We can select a window (in the GIF below I am using a bash terminal as target) and send any text to that window. This will be helpful in my teaching sessions. Specially modifying larger Python functions etc.

I am yet to go through all the Advent of Neovim videos from TJ DeVries. I am hoping to improve (and more features) to the plugin after I learn about plugin development from the videos.

Drupal Project Browser: Guide Editor Fri, 12/27/2024 - 10:12

"In the past 18 months, Project Browser has gone from announcement to beta. And the latest beta has a full-featured user interface for discovering and installing projects, fulfilling the original vision of users not needing a command line."
 — Dries Buytaert

Join me for an insightful conversation with Alex Monahan, who works on documentation, tutorials, and training at DuckDB Labs. We explore why DuckDB is gaining momentum among Python and data enthusiasts, from its in-process database design to its blazingly fast, columnar architecture. We also dive into indexing strategies, concurrency considerations, and the fascinating way MotherDuck (the cloud companion to DuckDB) handles large-scale data seamlessly. Don’t miss this chance to learn how a single pip install could totally transform your Python data workflow!<br/> <br/> <strong>Episode sponsors</strong><br/> <br/> <a href='https://talkpython.fm/sentry'>Sentry Error Monitoring, Code TALKPYTHON</a><br> <a href='https://talkpython.fm/citizens'>Data Citizens Podcast</a><br> <a href='https://talkpython.fm/training'>Talk Python Courses</a><br/> <br/> <h2>Links from the show</h2> <div><strong>Alex on Mastodon</strong>: <a href="https://data-folks.masto.host/@__Alex__?featured_on=talkpython" target="_blank" >@__Alex__</a><br/> <br/> <strong>DuckDB</strong>: <a href="https://duckdb.org/?featured_on=talkpython" target="_blank" >duckdb.org</a><br/> <strong>MotherDuck</strong>: <a href="https://motherduck.com/?featured_on=talkpython" target="_blank" >motherduck.com</a><br/> <strong>SQLite</strong>: <a href="https://sqlite.org/?featured_on=talkpython" target="_blank" >sqlite.org</a><br/> <strong>Moka-Py</strong>: <a href="https://github.com/deliro/moka-py?featured_on=talkpython" target="_blank" >github.com</a><br/> <strong>PostgreSQL</strong>: <a href="https://www.postgresql.org/?featured_on=talkpython" target="_blank" >www.postgresql.org</a><br/> <strong>MySQL</strong>: <a href="https://www.mysql.com/?featured_on=talkpython" target="_blank" >www.mysql.com</a><br/> <strong>Redis</strong>: <a href="https://redis.io/?featured_on=talkpython" target="_blank" >redis.io</a><br/> <strong>Apache Parquet</strong>: <a href="https://parquet.apache.org/?featured_on=talkpython" target="_blank" >parquet.apache.org</a><br/> <strong>Apache Arrow</strong>: <a href="https://arrow.apache.org/?featured_on=talkpython" target="_blank" >arrow.apache.org</a><br/> <strong>Pandas</strong>: <a href="https://pandas.pydata.org/?featured_on=talkpython" target="_blank" >pandas.pydata.org</a><br/> <strong>Polars</strong>: <a href="https://pola.rs/?featured_on=talkpython" target="_blank" >pola.rs</a><br/> <strong>Pyodide</strong>: <a href="https://pyodide.org/?featured_on=talkpython" target="_blank" >pyodide.org</a><br/> <strong>DB-API (PEP 249)</strong>: <a href="https://peps.python.org/pep-0249/?featured_on=talkpython" target="_blank" >peps.python.org/pep-0249</a><br/> <strong>Flask</strong>: <a href="https://flask.palletsprojects.com/?featured_on=talkpython" target="_blank" >flask.palletsprojects.com</a><br/> <strong>Gunicorn</strong>: <a href="https://gunicorn.org/?featured_on=talkpython" target="_blank" >gunicorn.org</a><br/> <strong>MinIO</strong>: <a href="https://min.io/?featured_on=talkpython" target="_blank" >min.io</a><br/> <strong>Amazon S3</strong>: <a href="https://aws.amazon.com/s3/?featured_on=talkpython" target="_blank" >aws.amazon.com/s3</a><br/> <strong>Azure Blob Storage</strong>: <a href="https://azure.microsoft.com/products/storage/?featured_on=talkpython" target="_blank" >azure.microsoft.com/products/storage</a><br/> <strong>Google Cloud Storage</strong>: <a href="https://cloud.google.com/storage?featured_on=talkpython" target="_blank" >cloud.google.com/storage</a><br/> <strong>DigitalOcean</strong>: <a href="https://www.digitalocean.com/?featured_on=talkpython" target="_blank" >www.digitalocean.com</a><br/> <strong>Linode</strong>: <a href="https://www.linode.com/?featured_on=talkpython" target="_blank" >www.linode.com</a><br/> <strong>Hetzner</strong>: <a href="https://www.hetzner.com/?featured_on=talkpython" target="_blank" >www.hetzner.com</a><br/> <strong>BigQuery</strong>: <a href="https://cloud.google.com/bigquery?featured_on=talkpython" target="_blank" >cloud.google.com/bigquery</a><br/> <strong>DBT (Data Build Tool)</strong>: <a href="https://docs.getdbt.com/?featured_on=talkpython" target="_blank" >docs.getdbt.com</a><br/> <strong>Mode</strong>: <a href="https://mode.com/?featured_on=talkpython" target="_blank" >mode.com</a><br/> <strong>Hex</strong>: <a href="https://hex.tech/?featured_on=talkpython" target="_blank" >hex.tech</a><br/> <strong>Python</strong>: <a href="https://www.python.org/?featured_on=talkpython" target="_blank" >www.python.org</a><br/> <strong>Node.js</strong>: <a href="https://nodejs.org/?featured_on=talkpython" target="_blank" >nodejs.org</a><br/> <strong>Rust</strong>: <a href="https://www.rust-lang.org/?featured_on=talkpython" target="_blank" >www.rust-lang.org</a><br/> <strong>Go</strong>: <a href="https://go.dev/?featured_on=talkpython" target="_blank" >go.dev</a><br/> <strong>.NET</strong>: <a href="https://dotnet.microsoft.com/?featured_on=talkpython" target="_blank" >dotnet.microsoft.com</a><br/> <strong>Watch this episode on YouTube</strong>: <a href="https://www.youtube.com/watch?v=3wGeadcKens" target="_blank" >youtube.com</a><br/> <strong>Episode transcripts</strong>: <a href="https://talkpython.fm/episodes/transcript/491/duckdb-and-python-ducks-and-snakes-living-together" target="_blank" >talkpython.fm</a><br/> <br/> <strong>--- Stay in touch with us ---</strong><br/> <strong>Subscribe to Talk Python on YouTube</strong>: <a href="https://talkpython.fm/youtube" target="_blank" >youtube.com</a><br/> <strong>Talk Python on Bluesky</strong>: <a href="https://bsky.app/profile/talkpython.fm" target="_blank" >@talkpython.fm at bsky.app</a><br/> <strong>Talk Python on Mastodon</strong>: <a href="https://fosstodon.org/web/@talkpython" target="_blank" ><i class="fa-brands fa-mastodon"></i>talkpython</a><br/> <strong>Michael on Bluesky</strong>: <a href="https://bsky.app/profile/mkennedy.codes?featured_on=talkpython" target="_blank" >@mkennedy.codes at bsky.app</a><br/> <strong>Michael on Mastodon</strong>: <a href="https://fosstodon.org/web/@mkennedy" target="_blank" ><i class="fa-brands fa-mastodon"></i>mkennedy</a><br/></div>

As a product owner assistant at Liip, I enable customers to get the most out of the products we build together. In this article, I want to reflect on the learnings I made during the relaunch of pharmaSuisse - the new platform of the Swiss Pharmacists Association.

Goodbye individual CMS, hello open-source CMS. The new websites of the Swiss Pharmacists Association are based on the open-source solution Drupal, including a decoupled frontend with Nuxt, an ERP integration, user account management, different commerce workflows, and a paywall that gives members exclusive access to content.

Running Multiple Products on One Platform

Together with pharmaSuisse, we chose to develop a platform that could feed multiple web presences:

• pharmasuisse.org is the place where all members (pharmacies and pharmacists) get access to relevant information for them, can buy products or change their data

• ihre-apotheke.ch is the place where the general public can find the pharmacy that best suits their needs

• fphch.org serves as an entry point for the education of pharmacists

All three sites benefit from the same base functionalities:

• A modern design system that can be slightly adapted to each website's needs

• Flexible content blocks & editing capabilities based on our Interactive Page Builder blökkli

• Two-way synchronisation with the Navision ERP system thanks to the Odata API Sync module

• Granular, role-based access controls that allow to serve premium content to association members behind a paywall

• Integrated shop system that serves 4 different product types such as physical products, e-learnings, digital downloads and licence keys with Drupal Commerce

• Powerful automated translation workflows thanks to the Translation Management Tool ecosystem  

• A form builder that allows editors to create online forms using webforms

Working with multiple Product Owners on one platform was an inspiration for me. For the planning, this means that we dedicate certain sprints to the particular needs of a platform. At times it was a challenge to consolidate the needs onto a unified platform, but for me, the advantages were evident in this case. Each increment didn’t only add to one of the site instances but would automatically benefit the others. The focus per sprint on a product helped the rhythm of the implementation and gave pauses and time for each Product Owner to prepare for their next turn.

Staging the Go-Live

We decided to go live with the smallest platform first. This gave us the opportunity to incorporate a good amount of learnings for the more challenging go-lives that came after that. If possible, I recommend going live with a smaller version of the product before doing a big bang launch where the risks of failure can be very high.

Adapting the Pace

The relaunch of this platform involved touching various integration points. A complex ERP integration and further interfaces needed to be implemented. Over the course of the project, we realised that the pace of delivery was not aligned and too fast in comparison to the pace of the other organisations involved. What helped us was taking breaks and using this time to get stories tested and resolve dependencies between systems. Since this experience, I try to implement sprint breaks after 2-4 sprints so that the affected people have time to use the system, incorporate the learnings, and revisit design or conceptual questions before we continue with further implementation cycles. 

Creating Feedback Loops and Transparency

With every complex project, the situation can change drastically over time. You get more insight into what is to be done, you identify shortcuts or other obstacles, and new ideas emerge. Using agile methods, we kept everyone up-to-date by delivering working software from day 1. We were able to update the forecast of how much work is left for the MVP to be finished. We could add new feature requests and drop one that we prioritised lower. Often these come with a trade-off, and especially if you relaunch a grown existing system, people are worried about all the important things they are used to and will lose. By maintaining transparency about what is possible in terms of time and budget, we navigated the scope discussions with the Product Owners and delivered the new platform within 10 months.

I would like to thank the three pharmaSuisse Product Owners, Simona Kröni, Jens Apel, Cristian Dias and the entire pharmaSuisse team, for your dedicated work in realising this web relaunch together with Liip.

Usually Architecture: any is recommended in debian/control except upstream explicitly doesn't/won't support that architecture.

In practical use case, linux-any is useful to exclude hurd architecture. (Previously it is also useful to exclude kfreebsd)

Here is the simple script to check whether specific architecutre matches linux-any or not.

#!usr/bin/bash TARGETS=" amd64 arm64 armel armhf i386 mips64el ppc64el riscv64 s390x alpha hppa hurd-amd64 hurd-i386 loong64 m68k powerpc ppc64 sh4 sparc64 x32 " for d in $TARGETS; do dpkg-architecture -i linux-any -a $d if [ $? -eq 0 ]; then echo -e "[\e[32m\e[40mOK\e[0m] $d is linux-any (dpkg-architecture -i linux-any -a $d)" else echo -e "[\e[31m\e[40mNG\e[0m] $d is NOT linux-any (dpkg-architecture -i linux-any -a $d)" fi done

screenshot of shell script

As AI continues to transform industries globally, ensuring openness and inclusivity in its development has become a critical mission. Initiatives like OSI’s recent Open Source AI Definition and broader discussions on Open Source legal and policy frameworks at events like FOSDEM underscore this growing importance. In East Asia, grassroots movements are taking the lead in bridging linguistic and cultural divides, promoting Open Source AI as a driver of equity and innovation. These efforts were front and center at COSCUP (Conference for Open Source Coders, Users and Promoters), one of the region’s premier Open Source gatherings, where conversations focused on democratizing AI and exploring how public sectors and enterprises adopt Open Source technologies.

Two key COSCUP partners—g0v Jothon, a civic tech community, and the Open Culture Foundation (OCF), an OSI affiliate—spearheaded dedicated discussions on these themes. This article delves into their sessions, shedding light on how advocates in East Asia are addressing critical challenges in these Open Source landscapes.

Photo by COSCUP shared under a Creative Commons (BY-SA) license

Open Data for Inclusive AI

g0v Jothon spearheads the “Traditional Chinese AI Open Source Implementation Project,” aiming to advance AI Open Source development for Traditional Chinese. This initiative supports six teams building high-quality Open Source datasets across domains like benchmarking, law, healthcare, parliamentary data, education and Taiwanese language resources. At COSCUP 2024, the project showcased its datasets, outcomes and application demonstrations. To date, it has generated over 238,000 entries of Traditional Chinese Open Source data, accessible to the public here.

The participating teams are impressively diverse. Some are formed by IT professionals, while others are led by companies specializing in linguistic data analysis. Interdisciplinary collaborations are also prominent, including partnerships between journalism foundations and startups, IT research labs and hospital doctors, and teams co-organized by teachers and technical experts.

Six Teams in the Traditional Chinese AI Open Source Implementation Project. Photo by g0v Jothon (CC BY 4.0)

Building a Sustainable Open-Source AI Ecosystem

g0v Jothon also hosted a cross-disciplinary forum on the “GenAI Open Source Ecosystem.” Panelists included representatives from Taiwan’s large language model industry, AI startup community leaders, Open Source application platform advocates, and civil AI community organizers. Moderated by the Secretary-General of Taiwan AI Academy, the discussion emphasized the importance of Open Source principles and strategies for generative AI R&D.

The forum also stressed that social responsibility in technology requires equitable access. Large corporations engaging in closed-source development were encouraged to contribute to the Open Source ecosystem. The presentations and forum videos are available on the project’s website.

GenAI Open Source Ecosystem Forum. Photo by CHR (CC BY 4.0) Breaking new ground with Open Source policy discussions

For the first time, the Open Culture Foundation (OCF) hosted an Open Source Policy track at COSCUP 2024. Inspired by insights from FOSDEM, OCF aimed to explore how policies—whether from governments, enterprises or communities—impact the Open Source ecosystem.

The policy track featured nine sessions attended by nearly 300 participants. The diverse speaker lineup included Open Source community leaders, NGO advocates, researchers and government officials.

Key sessions:

• My Experience Creating Open Source Projects in the Government
  TonyQ shared a compelling narrative of his journey from external collaboration with government agencies to becoming an internal advocate for Open Source initiatives within the public sector. His session notably explored why promising Open Source projects within government often fade away despite initial momentum, highlighting the structural and cultural challenges that need to be addressed for sustainable implementation.
• The Business Dilemma of Open Source Projects
  Date Huang provided a comprehensive analysis of Open Source business models, drawing from real-world examples. He examined various approaches, from support-based services to pay-for-specific-version models, detailing the specific challenges each faces. His discussion particularly resonated when addressing the ultimate challenge: maintaining project sustainability while preserving the core values of Open Source development.

Tony Q shares experiences conducting Open Source projects in the public sector. Photo by COSCUP (CC BY-SA)

Date Huang discusses the business dilemmas of Open Source projects. Photo by Open Culture Foundation (CC BY 4.0)

While COSCUP has previously hosted policy-related discussions, these were often scattered across different tracks, making them challenging to follow systematically. The dedicated policy track revealed a pent-up demand for structured dialogue on Open Source policy matters. Particularly encouraging was the enthusiastic response to government representatives’ participation, with extended post-presentation discussions reflecting the community’s keen interest in public sector engagement.

The success of this first policy track suggests promising potential for future development. Looking ahead, organizers hope to establish it as a permanent fixture of COSCUP, expanding both the breadth of topics covered and the depth of discussion. This could include more focused sessions on specific policy issues and enhanced opportunities for substantive dialogue between stakeholders.

This new addition to COSCUP demonstrates the growing recognition that Open Source success depends not only on technical excellence but also on supportive policy frameworks and engaged stakeholder communities.

All about people: Why COSCUP is a key convergence point for Open Source

COSCUP, organized entirely by volunteers, is a vibrant hub for Open Source enthusiasts to exchange ideas. Now in its 20th year, it attracts 3,000 attendees annually. The event collaborates with global initiatives, such as the Celebrating 25 Years of Open Source campaign led by the OSI and the global Open Source survey led by the Linux Foundation. These partnerships underscore COSCUP’s significance within the global Open Source community, cementing its place as a favorite event among advocates.

Curious to learn more? Read COSCUP Unveiled by Paloma Oliveira.

Volunteers promoting OSI campaigns during the event

Participants share details of upcoming Open Source gatherings during the event

For Inquiries:

• g0v Jothon: jothon-organizers@g0v.tw
• Open Culture Foundation: hi@ocf.tw
• COSCUP: engagement@coscup.org

You can also meet OCF and COSCUP in person at the upcoming FOSDEM25, where they will host a stand at the event.

This article is contributed by Amos Li from OCF, Che Wei Liu from g0v Jothon, and Peter H.R. Chu from COSCUP under CC BY 4.0.

Last year I decided that I want to share my most important learnings about engineering, teams and quite frankly personal mental health. My hope is that those who want to learn from me find it useful. This is a continuation to this.

Over the years, I've been asked countless times: “What advice would you give to young programmers or engineers?” For the longest time, I struggled to answer. I wasn't sure I had anything definitive or profound to offer. And truthfully, even now, I'm not convinced I have enough answers. But as I've reflected on my journey to here, I've formulated some ideas that I believe are worth sharing — if only to provide a bit of guidance to those just starting out. For better or worse, I think those things are applicable regardless of profession.

My core belief is that fulfillment and happiness comes from deliberate commitment to meaningful work, relationships, and personal growth and purpose. I don't claim that these things can be replicated, but they worked for me and some others, so maybe they can be of use for you.

Put Time In

Putting time into work and skills — and by that truly investing oneself — is always worth it.

Whether it's working on a project, solving a difficult problem, or even refining soft skills like communication, the act of showing up and putting in the hours is essential. Practice makes perfect, but more so it's all about progress rather than perfection. Each hour you spend iterating, refining, failing and retrying brings you closer to excellence. It doesn't always feel that way in the moment but when you look back at what you did before, you will see your progress. And that act of looking back, and seeing how you improved, is immensely rewarding and in turn makes you enjoy your work.

I did not start out enjoying programming, not at all. I had a friend in school who was just better than me at everything. It felt demotivating. Programming turned out to be a necessary tool that I had to build things and to share with others, and through that, I eventually ended up enjoying it.

There is a narrative that working hard is inherently bad for your health or that long hours lead to burnout. I disagree. It's not about how many hours you put in, but about the enjoyment and quality of the work you're doing. Still some of my most favorite memories were some all-nighters I did when I was younger working on something. It wasn't even necessarily on projects that ended up meaningful or successful, but it was the act in itself. When you find joy in what you're building in the moment, work does not feel like a burden. Instead it feels exciting and exhilarating. These memories, that some might describe as unhealthy are some of my most pleasant ones.

Work And The Man

The key isn't avoiding hard work but finding meaning in it. Practice and effort, when coupled with a sense of purpose, not only make you better at what you do but also make the journey itself fulfilling. There is one catch however, and that is that your payout should not just be your happiness in the moment, but it should be long lasting.

The best way to completely destroy your long term satisfaction is if the effort you are putting into something is not reciprocated or the nature of the work feels meaningless. It's an obvious privilege to recommend that one shall not work for exploitative employers but you owe yourself to get this right. With time you build trust in yourself, and the best way to put this trust to use, is to break out of exploitative relationships.

If you end up doing things you do not believe in, it will get to you. It will not just demotivate you and make you unhappy at work, it will eventually make every hour you spent miserable and eventually get to your health.

Other than sleeping, work is what you spent the most time with for a significant portion of your life. If that is not fulfilling a core pillar of what can provide happiness is not supporting you. I have seen people advocate for just not caring to fix the work aspect, instead to work less and spend more free time. I have not found that to work for me. Work needs to be fulfilling, even if work is just a few hours a day.

Dare To Commit

Life isn't about sampling everything; it’s about making deliberate choices and committing to the ones that matter. You don't need to date twenty people to find the right partner, nor do you need a network of hundred acquaintances to succeed. Similarly, you don't need to work at ten different companies to build a meaningful career. Those things can be hugely beneficial, don't get me wrong, but you can do more with less too. When you focus on taking one step at a time, choosing the best option available to you in that moment you can accomplish great things. Feel free to look to others for inspiration, but do not to compare what they have versus what you don't. Nothing good will come from that. Everyone's journey is unique, shaped by the opportunities they encounter and the paths they decide to follow. Value grows not with the breadth of options explored but with the depth of commitment to the path you've chosen.

Just as mastering a skill pays dividends, so does committing on your personal or professional journey. Even if the world around you shifts — like the rise of AI in software engineering — your experience and expertise aren't wasted. Your gained experience makes it much easier for you to adjust course and it will give you the necessary trust in yourself. It allows to leverage what you've learned in new ways. While it's true that choosing from limited options might not always lead to the “best” possible outcome, the time and effort you invest in your chosen path can often outweigh the hypothetical gains of a different choice. In many cases, mastery and fulfillment come not from chasing endless possibilities but from fully embracing the one path you're on and making it your own.

Date to Marry

To me this happened through a lucky accident but it's something I strongly believe in. I'm an agnostic, I don't hold strong religious beliefs but I do believe in the purpose of and benefits of a lasting marriage. When my wife and I met I did not think I was in a position in my life where I had interest, desire or necessity in a deep relationship, let alone to marry. We did not live in the same country when we met and we had a long distance relationship for almost a year. That kind of relationship (particularly when visa issues are involved) has one incredible benefit: you really have to commit to your relationship. It's expensive and you spend a lot of time talking and sharing intimate thoughts. It also forces you to make a concious decision if the two of you believe it's worth continuing. You don't have the option to just “test drive” it. It forces you to figure out all the hard things upfront. Career, values, ambitions, children, the whole thing. That's a very different experience to swiping right and see what comes from it.

That one year of intensive dating changed me. I started to recognize the benefits of committing to something on a much deeper level. It taught me that vulnerability and opening yourself up can be a beautiful thing. It showed me that there was a whole part to myself I did not look into. It showed me that really committing to something, opens up a whole new world of opportunity and it allowed us to really invest into our relationship.

When you commit to your partner fully you get a lot in the process. Yes, there are risks and while you're dating, you need to figure these things out. You need to know on a fundamental level that the person you're dating is going to be the one you want to be with for a lifetime. That's not easy, because no human is perfect. Yet if that is the goal, you can poke at the parts where dragons can be. Only in situations of stress and challenge will you truly find out how the other person works and if that works for you.

I have heard people talk about “going to IKEA” for a date. I think that's a brilliant idea. Imagining a life together and struggling a bit through conflict and resolution is exactly the right way to go about it.

Having Children

Very few things have so profoundly changed me as our first child.

Seeing children grow up is such a moving experience. I enjoy being with them in moments of achievements or sadness alike and I love when they surprise me in the morning with their newfound wisdom or after school with their proud achievements. It's fun to play with them, to help them learn new things and you can do things together you haven't done since your own childhood.

I'm lucky to have kids. I grew up in a society that has largely painted a pretty dark picture about having children but I do not share those views. We knew we wanted children and I'm glad we didn't wait. You can't cheat nature on this thing and at the present state of scientific development, things still are much harder if you try to have children late.

Nothing will ever be perfect. There were sleepless nights, there are the sicknesses that come in autumn with daycare and school. You need to arrange things in different ways than you were used to. You will hear a lot from parents and educators about what is is like to have children but the reality however is that I don't think it's possible to know how it is to have kids until you do. In a way you have to jump into the cold water and there is no going back.

There are some important prerequisites though, but I think differently about them now then I did before. I don't think that you need a lot of money or a stable career, but you need to have your marriage and house in order. The most important thing I learned about having children is that you first and foremost need to take care of yourself. Any stress you experience, you will pass on to your children and it will harm them in the process. This is really important. There are lots of dysfunctional households and bad parents and you should not have children if you can't take care of yourself.

Those are the important parts, but then there are superficial issues. I almost entirely opted out of reading parental advise books because I could feel how they stress me out. I found it easier to take on challenges as they arrive naturally. If you have a loving relationship with your spouse you can extend that to your children and learn how to deal with challenges calmly (or as calmly as you can). You need to be there for each other. Your children will not become more successful because you mastered breast feeding on day one or if you taught them sign language before they can talk. They will however be significantly better off if you can jump on a moment's notice to take care of your spouse or child when something goes wrong.

Our experience is unlikely to be your experience, but there are some things that are shared among parents. You grow above yourself when all the sudden become fully responsible for another human being and you can't opt out of it. It also invites you to reflect on yourself more and how you came to be the person that you are. I also don't think it makes you any less ambitious, but it changes how you define success for yourself. Your horizon opens up and it really makes you think more about the totality of your family rather than yourself.

My life isn't about perfection or constantly chasing what's next; it's about being present and committing to the things that matter. This is also what I'm passing on to my children. Whatever your journey may look like, I hope you find joy, purpose, and the courage to commit fully to it and that you found something useful in my writings.

Significant changes arrive with Drupal 11.1, marking a shift in how developers work with content types and hooks.

No More Default Body Field

The default body field will no longer be automatically generated when you create a content type. This change moves away from the traditional standard where the body field serves as the primary content container. In the past, when starting a new Drupal site, the body field was always expected to be present. 

It was a standard feature that developers relied on. Now, new sites will have various field names such as `field_description`, `field_text`, and `field_content`. This shift in naming conventions may lead to some adjustments in how content is managed.

But I noticed that the body field was slowly being phased out and replaced with the paragraph field, where instead of adding all your content into a single field, you would build out your page using paragraph types, or as we would often call them, components.

Join Mukesh Agarwal, CEO of Innoraft, as he recounts an unforgettable experience at DrupalCon Singapore 2024—the first Asian gathering of Drupal enthusiasts in nearly a decade. This landmark event showcased cutting-edge innovations, visionary insights, and community-driven contributions that are shaping the future of the Drupal ecosystem.

From the highly anticipated launch of the Drupal CMS Release Candidate to the inspiring 41st Driesnote and hands-on workshops exploring the latest technological breakthroughs, the conference was a celebration of innovation and collaboration. Mukesh shares key highlights, technical revelations, and the spirit of community that makes Drupal more than a CMS—it’s a movement.

Dive into the highlights and discover how DrupalCon Singapore 2024 has set the stage for a transformative 2025.

Dries Buytaert announced the Experience Builder Initiative earlier this year, with the aim to become the default Drupal tool for layout design, page building, and basic theming. The main goal is to create a tool that site builders love, with an amazing out-of-the-box experience. The development of Experience Builder is going very well with the first stable release expected in late 2025, at which point it is also planned to be part of Drupal CMS 2.0.

Complementing the tool, a month ago we published a call for partners to design and implement a comprehensive design system for Experience Builder and thus Drupal CMS. Now we’re thrilled to announce that we have selected Mediacurrent as the partner to collaborate with on this project!

We were amazed by the quality, creativity, and expertise demonstrated in the proposals submitted by our community. In the extensive evaluation process, the selected partner stood out for their thoughtful approach, in-depth understanding of user needs, and a clear actionable roadmap. Their proposal reflected a strong focus on usability, accessibility, and scalability, ensuring the design system will empower designers, developers, and content marketers alike.

To maintain transparency with the community and celebrate the exceptional quality of their work, we’re pleased to share the winning proposal. You can see an overview of activities and high-level timeline and their design system showcase. Thanks to Mediacurrent for being willing to share your proposal with the community.

Work on this exciting project will kick off in January, with an early preview of the work for DrupalCon Atlanta in March 2025 and a stable release later in the year.

We want to thank everyone who submitted a proposal and contributed their time, effort, and creativity to this initiative. We’ve had an impressive turnaround that shows how the Drupal CMS project is bringing the community together to work towards the same goals.

Stay tuned for updates as we progress on this exciting journey!

Did you know that Python's types library has a bunch class implementation? How did I not see this before?!

Drupal Advent Calendar 2024 Addendum - The Drop Times and 24 Days of Automation james Tue, 12/24/2024 - 23:30 Image Body

I hope you enjoyed this year’s Drupal Advent Calendar, and our whistle-stop tour of Starshot tracks. If you missed it, you can catch up here.

I want to touch on a couple of things that I missed during the regular calendar schedule.

The Drop Times

The Drop Times is a Drupal news site that covers everything happening across the Drupalverse. They do a superb job of covering DrupalCons and Drupal Camps around the world. Since the announcement of the Starshot initiative, they have been dutyfully covering all the news from the initiative, and they have been a valuable source of information when…