Simone Robutti

Let’s say you’re a small to medium-sized organization where multiple people or units are in charge of planning and promoting public events. For example: you could be an agency, a publisher, an advocacy group, or a small political organization.

Let’s say you’re not satisfied with the amount of manual work that planning and promoting events requires. Let’s also say that you’re technologically savvy enough to understand the existential threat and implications posed by the adoption of Facebook Events or Meetup.com. For example, Facebook might decide to suspend your page or that you’re not the owner of the business or organization represented by the page. Appealing such decisions takes time and very often results in a loss of followers or engagement.

In the last few years, awareness about technological autonomy and the threats posed by dependency on major social media platforms have led many organizations to reconsider their media strategy due to the growing number of examples of businesses, NGOs and individuals that have suddenly lost access to their audience. Mounting concerns such as these have led to an increased interest in technological autonomy, touching communities much broader than old-school privacy-obsessed hacker niches.

This post will document a strategy to start tackling the issues related to “event liberation”: the idea that your ability to create events and your audience’s ability to discover and attend your events shouldn’t depend on technologies outside your control. I will describe how Tech Workers Coalition Italia currently approaches event promotion, illustrating the interaction design, the tools used in our strategy, the technical details of its adoption and the concerns of technological autonomy that informed our architecture.

To begin, here are our priorities:

  • technological autonomy
  • reduction of manual work
  • distributed control inside the organization
  • support for lean processes
  • customization of our social media strategy

Some assumptions about your organization:

  • you care about the stuff above
  • you have your own server
  • you have a sysadmin, or you are used to working with one

Meet the Star of the Show: Mobilizon

Mobilizon is a federated tool to host and discover events. It’s organized through so-called “instances”, independent servers connected to one another that are controlled by different organizations or individuals. In short, “federated” means that you can host your instance of Mobilizon on your server at mobilizon.mycoolorg.xyz, but whoever accesses the website can see the events of many other Mobilizon instances. The opposite is also true: events published on mobilizon.mycoolorg.xyz will be visible to whoever decides to “federate” with your instance. This mechanism allows autonomy and control over your data, but at the same time allows discoverability and aggregation on a global scale. If you want to dig deeper into federated technologies, you can look up some keywords like “fediverse” or tools like Mastodon.

Mobilizon is central and critical to the strategy we are going to explain because it will be the “source of truth” for all your events: you can plan them, set a date and location, create thorough descriptions, track RSVPs. It also allows a group of users to publish events under a single identity. This might come in handy, for instance, in umbrella organizations because you can give different permissions to different users in your group and have fine-grained control without having to share credentials.

On its own, Mobilizon won’t bring much visibility to your events unless you target the few niches that have already embraced this software. This is not much of a problem for us. Let’s see why.

Some fancy diagrams

To understand the big picture, we need to detail two flows: 1. The event journey through the platforms 2. The user journey through the Funnel

What are the current strategies to event distribution employed by most organizations? They schedule all the events manually and publish the event on a platform like Facebook Events, Meetup.com, Eventbrite, and so on, then manually add it to their website and subsequently publish them on your social media platforms. In practice, this not only means a lot of clicking, but also that you either give access and training on multiple platforms to anybody that can organize events, or you create a bottleneck where the promotion of events has to go through a single person or team, slowing down the entire process. Alternatively, you might choose to promote events only through one or two of your most-trafficked social media platforms, underutilizing the potential reach of your online presence.

A manual process is annoying, costly and error-prone. When we were designing processes for Tech Workers Coalition Italia, we understood that many organizations view event promotion as a major source of issues. Thus, we decided to employ a different strategy as soon as we were able to maintain it.

So what’s the strategy? First, we publish events on Mobilizon. Mobilizon will empower our website to pull event information and synchronize said information. At this point, a dedicated tool called mobilizon-reshare will automate the publication of events on our social media. This will keep the manual work to a minimum; for most scenarios, the members of your organization responsible for publishing events won’t have to learn any other tool beyond Mobilizon.

We picked Mobilizon for a reason: it is going to store our ground truth. The “golden copy” of the event sits on Mobilizon and everything else will ask Mobilizon for the list of upcoming events. Mobilizon becomes our central point for event planning—it comes with its own editing interface, permissions system, and all the structure we described in the previous section. On top of that, it offers a comfortable GraphQL interface to query the data, even without authentication.

In Tech Workers Coalition Italia, we believe that technological autonomy from big platforms are goals in line with both our self-interest and organization values. If your internal processes and your visibility depend on tools external to your organizational control, your organization is susceptible to aftershocks when these tools fail. We know many stories of small businesses or organizations that got kicked out of Facebook and Instagram, lose their followers without appeal, and fail to get back on their feet.

Therefore, we want to use Mobilizon to bring users away from big platforms and towards tools we control. In this diagram, we present an example illustrating our approach in TWC to thinking about how to direct users towards controlled tools and how the architecture fits into the overall strategy.

This is our funnel. In marketing lingo, a funnel is a model of how your users are moving or should be moving through different channels. In our context, we want our users to move through our social media pages, groups, or other digital channels.

The idea is to put tools under our control at the end of the funnel: a self-hosted Mattermost, a mailing list or a newsletter, maybe a Discourse forum. This way, in a catastrophic scenario, you will still retain the bulk of your followers and engage them to come to your events. Social media platforms become less crucial to your organization’s success, serving as a gateway to forward committed users, customers, and participants towards tools such as a newsletter where you can build a consolidated contact list or a Mattermost server dedicated to your community.

In our strategy, Mobilizon is not the platform where we want to gather and engage our users. Some users might sign up to your instance, especially if you require an RSVP, or follow your events through the iCal feed. You might reach some of them again, but Mobilizon is too new of a platform and most casual users won’t know what they can do with it. You probably don’t want to take the burden of bridging this cognitive gap. Mobilizon ends up taking a secondary role in the eyes of the casual user. We assume that some of them will eventually be interested in Mobilizon, therefore registering and growing the user base of the instance.

The viability of the whole approach is heavily dependent on your organization’s needs and goals, and it might not apply. The adoption of Mobilizon and mobilizon-reshare is not strictly dependent on a funnel design like ours, but we presented our version to give an example of the possibilities.

Automate your Social Media Manager

So, let’s move on and talk about the technical bits. As we saw in the previous section, we integrated Mobilizon in two ways: the first, with TWC’s website; the second, with our social media platforms.

The integration with the website is conceptually quite straightforward: you can use an existing plugin for the CMS powering your website or develop your own to make a GraphQL request to Mobilizon, cache the events locally, and render them the way you like. If you use Jekyll or WordPress, for example, there are already plugins that support this behavior. Resorting to this approach, you will have the list of events both on Mobilizon and on your website, but you won’t have duplicated data, manual work, or inconsistencies between the two.

Now, let’s move on to something a bit more complicated: promoting the events on social media. The “traditional” way involves entrusting somebody to manually create posts on each platform, format the content, maybe insert the dates, location, and other info about the event into dedicated fields and finally schedule the post so that it doesn’t conflict with the rest of the content plan. If you’re a professional, you might use dedicated software to track and publish on different platforms, but there’s still plenty of manual work to be done.

Now, mobilizon-reshare wants to address this problem by allowing an organization to automate some or all of these steps through an application that can be run on your server, giving you full control and privacy. The main feature of mobilizon-reshare is the possibility to download events from Mobilizon, decide if it’s time to publish an event and if it is, publish it on all the configured platforms.

Currently, in version 0.2, the supported platforms are:

  • Facebook
  • Mastodon
  • Twitter
  • Telegram
  • Zulip

You can control the behavior of the tool by executing it in specific time windows and days (for example using cron) and by specifying options such as the length of the minimum break time between two events. This will prevent you from publishing a burst of events by mistake or at times when the expected engagement is very low, while at the same time not having to worry about planning and scheduling every single event. Events get published in your Mobilizon group by somebody in the organization and at the first valid slot, the scheduled event will go live.

mobilizon-reshare also offers a “recap” feature when you want to publish a summary of upcoming events that have already been published on a given platform.

There are many more goodies:

  • Customize the templates used for each platform
  • Interact manually through the CLI to retry failed publication attempts and troubleshoot your publication strategy
  • Format events using the template engine without having to publish automatically. For example, if you want to avoid manually composing posts for every platform, mobilizon-reshare is still in a very early phase even though it fully supports the scenarios we just described, and it’s used in production in Tech Workers Coalition Italia. The project is currently looking for more Python developers to tackle the ambitious roadmap necessary to turn it into a mature social media suite.

This, in the short term, includes:

  • Support for more platforms
  • Easier configuration
  • A web interface to allow non-technical users to use the tool
  • Support for providers interested in offering mobilizon-reshare alongside Mobilizon

Conclusion

I hope this article will inspire you to tackle events in your organization from a new perspective and liberate them and yourself from dependency on big platforms. We have seen how to adopt Mobilizon and integrate it with different platforms. We have seen how to propagate events on multiple platforms automatically. Likewise, we have seen how such tools can be used as a part of a strategy adaptable to multiplying the potential of a small organization or to handling the complexity of a big organization.

Event liberation is part of a bigger change happening in the IT world that aims at liberating every form of data, personal and collective, from the silos created by a few companies. Mobilizon is just a small component of the fediverse that in turn is just one of many when it comes to the liberated software ecosystem of the future. Event managers and organizations are growing alongside these new technologies in a symbiotic relationship. Hopefully this approach will prevent the mistakes of the movements that in the last decades tried to liberate software only to discover that, if liberated software is suitable only for a niche of tech-savvy individuals and not for organizations, communities and exploited individuals with no time to develop technical skills, systemic change won’t happen and technology will be dominated by the most usable and available options.

I haven't been writing videogames' reviews in many years now and I'm not changing my mind, but I want to talk about a videogame anyway: Mindustry. You can buy it for 5€ on Steam or just download a .jar file from Github and run it.

screen1

The game in itself is well thought, well designed and well executed. I don't want to go in detail about the merit of the game itself, but let's try to understand what it is about. It falls in the category of automation games, like for example Factorio, but it has much more prevalent Tower Defense elements. The player can dig up (infinite) resources, move them around and combine them in increasingly more complex chains through factories and different transporation methods. These resources can ultimately be fed to many different kinds of towers that will help you defend from waves of enemies, together with bots that can be created in dedicated factories. While these basic mechanics are just few and simple, Mindustry gives it a very horizontal width by allowing the player to build a big number of towers, fuel them in many different ways through a diverse set of production chains.

While the premise looks similar to Factorio (minus the ecologist message), the gaming experience is very different: Mindustry is faster, more multiplayer/PVP oriented and more open to personalized strategies. It is challenging without being (too) frustrating. In campaign mode, it introduces you to concepts gradually and leaves you enough time to experiment with them without being unnecessarily slow or repetitive. The sessions, both in single player and multiplayer, are shorter and more influenced by the specific layout of the map. Again, if you liked Factorio, you will like Mindustry but not because it's a “more of the same”.

screen2

What I want to talk about is something else. This game delivers a mature, cohesive, polished visual and gaming experience that, in my opinion, is rarely matched in an open-source game and the developer(s) should be commended for it. If you have been involved in an open source game development, you know how hard it is to give artistic and design coherence to the work of multiple developers. Mindustry, for what I know, took a different path: it is the product of mainly one developer, Anuken that open-sourced the game while retaining ownership of the development.

This is his main project and he took a rather bold strategy to promote it compared to most indie developers that follow more traditional monetization strategies. Nonetheless the game fits this model perfectly well: it's small enough, it has many orthogonal elements of gameplay, it has serendipity and small mods give a lot of added value. There are clear sinergies between its Open-Source nature and the design of the game.

Contrary to many other open source games that aim at reproducing commercial games (like 0 A.D. or FreeCiv) or others that target micro-niches of hardcore gamers (like Cataclysm: Dark Days Ahead), Mindustry has the ambition to create something new that caters to a wider audience. It delivers a real and proper game and not a toolbox to build your own gaming experience like too many niche games are doing. Not that this is bad, I've been a hardcore Dwarf Fortress fan for years and I loved games like Cataclysm or Aurora 4X, but it's now time for open source games to target a different crowd.

On top of this, the whole process of contribution and release is very well structured and trasparent. The documentation is ok and it's very easy to enter the development process. The game is developed in Java with LibGDX and on a technical level shouldn't be challenging to contribute to. I've used the library in the past without previous knowledge on gaming development and I managed to achieve very good results in a relatively short span of time.

editor

The project is now just two years old and just landed on Steam, but as I said, it's already an extremely enjoyable experience as it is and has a very active community around it, with populated online servers. Is the game enough to start a new page of Open Source gaming? Probably not. Nonetheless is a small pearl that everybody in that world should consider as a blueprint to open up their projects. I hope that in the future the main developer will document better his subjective experience and give tools to other developers to emulate him.

When you first learn Python, somebody explains you that you can add the folder in which your source files sit to the PYTHONPATH environment variable and this code will then be importable from other locations. Too often this person forgets to say that this is a very bad idea in most scenarios. Some people discover this on the internet, some others just realize this by themselves. Too many people (especially non-programmers) just believe there's no alternative.

This blog post is for all of them, because even if you know that an alternative exists, it's not always easy to grasp. Python tooling is confusing because there are many software, built on top of each other, with a lot of overlaps with their concerns. It's hard to understand how they fit in the big picture.

For this reason I've decided to create a post that lists the most important tools, when and why they are used and what problem they solve. I will try to explain with simple words how you should approach each one of these tools. If a tool is here, it means that, as a Python programmer, you're supposed to at least know its existence. I will list only tools that can be applied to any project or workflow and that you should consider every time you start a new project. This doesn't mean you always have to use each one of them on every single project. Too much tooling can be easily be an overkill and become hard to maintain in some cases.

Basic

Setuptools

Setuptools is the standard way to create packages in Python. It's everywhere, it works and it fulfill its role.

For: building egg, zip or wheel files from source, define metadata for your project, share code in a structured and standardized way When: basically every time you want to write code that should run on somebody's else machine

Alternatives: Poetry, Flit

virtualenv

Virtualenv is a virtual environment manager. These isolated environments can be understood as self-contained python installations with independent packages installed. Using virtualenv means that you don't need to (and you shouldn't anyway) install packages using your default system's python installation.

For: keeping your dependencies separate, supporting multiple python versions in the same system, moving dependencies around easily When: you want to develop code, when you want to use a python version different than your default without going crazy

Alternatives: Docker or equivalent

Pip

Pip is the most common package management tool for Python. It allows you to take local or remote packages and install them in your virtual environment or system's Python.

For: installing and uninstalling packages, tracking versions of the packages you're using When: always

Alternatives: Poetry, Conda

Packaging and Distribution

For a more detailed overview, python.org has a dedicated [page].(https://packaging.python.org/).

distutils

distutils is a precursor of setuptools. The latter makes heavy use of features from distutils so it's not uncommon to have to interact with this tool. It's not something you should pick for your tool belt directly but you should be aware of where it fits in the big picture.

Pypi

Pypi is the Python Package Index. It's a big repository of all your favourite Python Modules. Pip, for example, takes built packages from here.

For: publishing your code When: when you have a package that you want to make publicly available

Pypiserver

Pypiserver is one implementation of the Package Index API used by Pypi. You can set up your own repository, for example for your whole company and publish packages there without releasing them to the public.

For: sharing code inside an organization When: this code shouldn't go public and you want to have control Alternatives: Warehouse (the one used by Pypi), djangopypi

Poetry

Poetry is an alternative packaging system that replaces setuptools, pip and some of the tools built on top of them. It's an attempt to do a complete overhaul of how the Python packaging system works. So far it got some traction and lot of positive feedback but it's far from being the prevalent option.

For: handling and distributing packages, managing your dependencies, avoiding dependency resolution problems When: you have a fresh project and you're not afraid to use a relatively niche tool Alternatives: Pipenv

Pipenv

Pipenv, like Poetry, is a tool to structure your Python project dependencies and configurations in a more sane way. Through a Pipfile, it manages the dependencies for your project and ensure consistency and ease of use.

For: handling and distributing packages, managing your dependencies When: you want something like Poetry that will raise less questions Alternatives: Poetry

Documentation

Sphinx

Sphinx is a tool to build documentation. It was born originally to handle Python's documentation but has now graduated to a general purpose documentation tool. It remains the most common option for Python Projects.

For: producing PDF or HTML documents from reStructuredText sources When: you want to have external documentation for your project, your APIs and your code Alternatives: Docutils, Doxygen

autodoc

autodoc is a fundamental extension to Sphinx that allows you to generate restructuredText files from Python source code with entries for each class, function, module and so on.

For: documenting your code or APIs When: probably every time you're using Sphinx for a project Alternatives: autosummary

Testing

py.test

py.test is, in my opinion, the best test suite available in Python. It has plenty of features even though not all of them are presented properly so it takes some time to discover all the many possibilities supported by this software

For: testing your code When: always, you lazy ass Alternatives: unittest, nose

Hypothesis

Hypothesis is a tool for property-based testing. Briefly said, it generates random test scenarios according to your specifications until it finds a case that makes your test fails. Take some time to learn the principles behind before starting to use this tool.

For: testing code, especially data processing When: you need to test non-trivial logic with a wide input space (numbers, strings, structured data)

tox

tox is at its core a virtualenv manager for testing. It means that you can configure it to run your tests in a series of clean, customizable virtual environments to ensure that your code will be able to work under different conditions. All of this without any manual work required.

For: code that needs to run in different conditions and environments. Also useful for CI. When: your code needs to support different Python versions, run in different environments and in different operative systems Alternatives: bash scrips, CI pipelines

Other

pyenv

pyenv is a python version manager. It aims to simplify the local workflow of developers when handling multiple versions.

For: running different projects with different python versions When: you need to run with global python versions and you have many Alternatives: manual management, virtualenv, Poetry, Pipenv

PyScaffold

PyScaffold is a tool to initialize your project structure in a standardized way and to provide some of the tools we listed before without need to configure them manually. It's heavily customizable.

For: bootstrapping projects, have multiple projects with uniform tooling and structure When: always (as long as you know the tool, don't use it the first time if you're in a rush) Alternatives: python-project-template, Cookiecutter

flake8

flake8 is one of the most used linters for Python. It runs different scripts to verify the compliance of your code with Python's style guide requirements (PEP-8).

For: verifying and guaranteeing good code style in your project When every time your project needs to be read by somebody, including yourself Alternatives: pylint

Black

Black is an automatic code formatter. It means that instead of just checking your code for compliance, Black will actually modify it to make it compliant.

For: formatting your code automatically When: you have no problem giving up manual control over your code look Alternatives: autopep8, yapf,

edit: I'm compelled to specify that this post is not to be taken seriously, it's satire if you want and most of the statements are ironical in nature. Don't take it literally.

Inspired by this post I've decided to write a post about the worst programming Language Names.

Programmers are often notoriously bad at naming things and sometimes managers help them too. This produced many specimens of badly named languages that made it harder to use and discuss them. Here are the ones I dislike the most.

SQL

How is it pronounced? Sequel or S.Q.L? And then a Sequel to what? It's too old, all those remember are probably dead or working as clerks now. Don't get me started with all the problems it creates with PostsgreSQL. Is it Postgres or Postgre?

Go

Go. Go where? And why? How is a novice supposed to Google it? Should we just call it Golang? It sounds too Oriental.

C

Can you at least make an effort and come up with a real name? It's not a name, it's a letter. If I call a variable “c” everybody gets mad, but apparently it's fine to call a language “C”.

Scala

Scala is a shortening of Scalable. Fair enough, that's clear. But in Italian it also means stairs. Therefore the logo is the staircase of an EPFL building, where Scala has been developed. The problem is that stairs are not really scalable. Also Teatro alla Scala is a very famous Opera House in Milan and it happened at least once that a lady came to the Milan Scala Meetup with a little kid, expecting it to be about Opera or something like that. They sat through the whole talk. It was something about monads. It's always about monads. Well, they should have picked a less ambiguous name.

Pony

I've recently entered the community and started to learn the language. I still sometimes forget to write “Ponylang” and Google keeps reminding me that the target audience of My Little Pony is single guys with hygiene problems. I just want to share mutable state between my actors without facing the horrors produced by modern society. Sean, I'm disappointed.

Enter your email to subscribe to updates.