Serverumzug die Zweite

Über 3 Jahre ist es nun her, dass wir das letzte mal auf einen neuen Server (damals der Server dragonfruit) umgezogen sind. Seit dem ist foodsharing immer weiter gewachsen und mehr und mehr Menschen nutzen die Plattform. Das sorgt auch für einen erhöhten Bedarf an Ressourcen.

Also haben wir wieder Kontakt zu unserem Server-Sponsor Manitu aufgenommen. Die Antwort auf unsere Anfrage hätte nicht besser sein können – Manitu hat einen gebrauchten Server für uns, der unsere Anforderungen erfüllt und stellt ihn uns kostenfrei zur Verfügung. Lediglich um die Beschaffung von neuen NVMe SSDs haben wir uns selbst gekümmern. Kostenpunkt: 222€ finanziert aus Spenden. Wer dazu beitragen will kann gerne auch Spenden: spenden.foodsharing.de.

Nachdem wir in einigen E-Mails alle Details geklärt hatten, hat Manitu die Server-Hardware für uns hergerichtet. An dieser Stelle noch mal ein großes Dankeschön an das Team von Manitu für den hervorragenden Support.

Am 1.10. haben wir dann nach einiger Vorbereitung den Umzug der Plattform vollzogen. Im Folgenden die ganze Geschichte noch mal etwas ausführlicher.

Planung

Bereits im Vorfeld haben wir überlegt, was wir alles ändern wollen mit dem neuen Server. Beim Betriebssystem sind wir bei debian geblieben, allerdings nun mit der aktuellsten Version bullseye. Die wohl größte Änderung ist, dass wir als Dateisystem nun zfs nutzen. zfs wurde insbesondere für Server entwickelt und bietet deutlich mehr Funktionen als klassische Dateisysteme. Durch den Wechsel mussten noch einige Änderungen z.B. an der Datenbank Konfiguration vorgenommen werden. Des weiteren haben wir für die Zertifikate von certbot auf acme.sh gewechselt und haben die Berechtigung der einzelnen Anwendungen weiter eingeschränkt, um den Schaden im Falle einer Sicherheitslücke weiter zu beschränken.

Der neue Server ist da

Nachdem manitu uns den Server vorbereitet hat, war natürlich die Frage nach dem Namen. Eine Umfrage ergab “onion”. Nun ging es an die Installaton. Dafür haben wir ein Live Debian genutzt und das eigentliche OS mit debootstrap installiert. Bei der Einrichtung des zfs Dateisystems sind wir überwiegend der Anleitung von OpenZFS gefolgt. Das neue System war also schnell da. Dadurch, dass wir schon sehr lange unsere Infrastruktur mit ansible verwalten war es auch sehr einfach eine foodsharing Instanz und alle weiteren Programme die benötigt werden zum laufen zu bekommen. Das Problem ist nur, wie kommen die Daten vom alten Server auf den neuen.

Die Umzugsvorbereitungen

Beim letzten Umzug wurde das kopieren der Daten und Datenbank noch händisch erledigt. Diesmal wollten wir es automatisieren. Also haben wir ein ansible playbook gebaut, dass die beiden Server auf den Umzug vorbereitet, den Code, die Zertifikate, die Daten und die Datenbank kopiert. Es funktioniert auch auf anhieb, also fast fertig.

Problem: Die Datenbank und die Daten müssen in einem konsistenten Zustand kopiert werden. D.h. sie können nur Kopiert werden, wenn die Seite aktuell nicht benutzt wird. Soweit so gut – bei unserer Datenbank die ~60GB groß ist dauert das knapp 2 Stunden. Natürlich schade, wenn die Seite so lange nicht erreichbar ist, deshalb haben wir noch ein mal nach Optimierungsmöglichkeiten gesucht. Unser Datenbankadmin hat noch mal etwas aufgeräumt und z.B. Alte Quiz Sessions gelöscht. Wir Admins haben noch etwas an der Datenbankkonfiguration geschraubt um die Datenbank möglichst schnell kopieren zu können. Mit folgendem Befehl konnten wir die Datenbank letzendlich am schnellsten auf den neuen Server übertragen. Ein Hoch auf Unix Pipes, die es ermöglichen in einem Befehl die Daten direkt in die neue Datenbank einpflegen und auf dem Dateisystem zur Sicherheit ablegen:

ssh root@dragonfruit.foodsharing.network "mysqldump --add-drop-table --add-locks --skip-comments --single-transaction --quick fsprod" | tee fsprod_migration.sql | mysql fsprod

Das Migrationsscript war also vorbereitet, mehrfach getestet, fehlt noch ein Termin für den Umzug. Die Auslastung des Servers zeigt, dass - abgesehen von Mitten in der Nacht – Samstag und Sonntag Vormittag die Nutzung der Seite am geringsten ist. Also haben wir uns für den morgen des 1.10.22 für den Umzug entschieden.

Der Umzug

Samstag morgen der 1.10. Ich war vor meinem Wecker wach. Also pünktlich um 07:46:23 das Migrationsscript angeworfen. Alles wird eingerichtet und installiert.

08:03:06 kommt die Meldung: „We are now going to migrate.“ Kurz noch mal alles Prüfen und los gehts – foodsharing ist erstmal nicht erreichbar und die Datenbank wird umgezogen. Die Zwischenzeit habe ich genutzt um die DNS-Records anzupassen (die Kollegen in Österreich und der Schweiz haben das auch gemacht), und die Anpassungen an unserer CI/CD-Pipeline vorzunehmen. Nach knapp 32 Minuten war die Datenbank umgezogen und um 8:40 war alles auf dem neuen Server vorbereitet. Was noch Fehlte: der neue Code aus der CI/CD-Pipline. Um 10:52:57 waren dann alles abgeschlossen und foodsharing war wieder erreichbar. An Feierabend war aber so früh noch nicht zu denken. Ein paar Dinge mussten noch angepasst werden – so haben wir z.B. neue Zertifikate für die verschiedenen Seiten ausgerollt, das Backup musste angepasst werden und noch weitere Kleinigkeiten.

Die erwarteten unerwarteten Probleme

Selten läuft alles Reibungslos. Bereits Ende März hatten wir durch ein Update von MariaDB Probleme mit dem Chatserver. Bei unseren Tests auf dem neuen Server trat das Problem nicht auf – jetzt wo wir live waren plötzlich schon. Wir hatten also ein akutes Problem. Wir hätten zurück auf den alten Server gekonnt, aber eigentlich musste das Problem irgendwann gefunden und gelöst werden. Also schnell unsere Entwickler zur Hilfe gerufen. Die Stelle mit dem Problem war bereits bekannt. Die Funktion fetchAllByCriteria is gibt ein leeres Array zurück, wenn die Anfrage zu groß ist. Warum? 🤯

Nach ein paar Tests konnte das Prolem schnell weiter eingegrenzt werden. Aber eine Lösung musste her. Durch das manuelle erstellen der Query, wie die Daten Abfragt konnte das Problem behoben werden.

Abschluss

Trotz der Probleme sind wir froh auf den neuen Server umgezogen zu sein. Die Auslastung ist nicht mehr durchgängig am Anschlag und die Ladezeit der Seite hat sich wieder verbessert. Wer sich das anschauen möchte kann das hier tun. Außerdem haben wir auch erstmal wieder Platz die hochgeladenen Daten und die wachsende Datenbank zu speichern. An dieser stelle noch ein mal Danke an manitu, die es uns möglich machen eine große Seite wie foodsharing kostenlos zu betreiben. Den bisherigen Server wollen wir in Zukunft für die foodsharing Cloud und andere Dienste nutzen.

A lot of you may be asking yourselves, why was it anounced that there is no more development on the foodsharing platform when it is now continuing? Why is development on foodsharing even continuing, although there was this yunity project trying to provide a replacement platform? And then there is sharecy as well?

Let me start with some words about me. I got to know foodsharing (then still lebensmittelretten.de) because I was seeing an ex-girlfriend interested on some foodsharing hamburg event in august 2014. Being a vegan for about a year, I was quickly fascinated of the idea of saving food and interacting with similar-minded people in the area, so I got into contact with Raphael Wintrich, the one who programmed the whole platform alone, at approximately the same time when I got my first foodsaver ID card.

​

xxxxxxxxxx

​

It’s time for the next foodsharing Hackweek!

Because of the Corona measures, we’ll be meeting online.

When - April 25th to May 3rd, 2020

Where - Online: Jitsi, Slack, Mumble…

We will discuss, program, give lectures to each other, and make foodsharing better together.

You can also participate for a few hours, it is worth it regardless of your own technical knowledge. The Hackweek is for both supporters and developers.

Let’s do this. ​ Matthias and Tilmann in a former Hackweek

this is a quite technical walkthrough of the process of finding the cause of todays outage. It is targeted to other server admins, so that we can learn from each other.

Breakfast

It’s 9 o’clock in the morning, I got my porrige and a coffee ☕, ready to watch the tagesschau, but my laptop prompted me with “foodsharing is down!!1!1!” instead.
dammit! but okedoki -> $ ssh dragonfruit.foodsharing.de

First step always if we get an 502 Bad Gateway error: what does nginx say?
$ tail -F /var/log/nginx/error.log

2021/03/30 06:40:12 [error] 1625#1625: *914973060 connect() to unix:/var/run/php7-fpm-production.sock failed (11: Resource temporarily unavailable) while connecting to upstream, client: 2003:*****:29bd, server: dragonfruit.foodsharing.de, request: "GET /api/stores/31605/pickups HTTP/2.0", upstream: "fastcgi://unix:/var/run/php7-fpm-production.sock:", host: "foodsharing.de", referrer: "https://foodsharing.de/?page=fsbetrieb&id=31605"

seems like php-fpm is down/unresponsive. After a restart it might work again, but lets have a look into the logs first to find out what causes the issue. but in non of the following sources yielded any hints

• journalctl -ef -u php7.4-fpm
• /var/log/php7.4-fpm.log
• /var/www/production/log/php-error.log

okay, let’s restart php-fpm: $ systemctl restart php7.4-fpm

Limits?

it works again! …. for a while… and then requests take forever … and then 502 errors again. Seems like something builds up. In which limits do we run here? Some research on that nginx error yields, that we might have too many sockets open. so lets temporary increase all limits we find, to see whether it changes something:

• $ sysctl -w net.core.somaxconn=60000
• $ sysctl -w net.core.netdev_max_backlog=60000
• listen.backlog in /etc/php/7.4/fpm/pool.d/production.conf

After another $ systemctl restart php7.4-fpm I had the feeling, that it might worked now a little bit longer, before we got the same error again.

Loops of playing with more settings and restarting didn’t lead to more information.

I already thought, that there could be an issue in the php code, but I deactivated already the beta ($ touch /var/www/beta/current/maintenance_mode_on) and there haven’t been any recent changes to production. Oke, but maybe there is really something somehow running long, stacking up open requests?

Eureka!

After activating the slow log (request_slowlog_timeout = 5s in /etc/php/7.4/fpm/pool.d/production.conf), there are a lot of entries in /var/www/production/log/php-slow.log like

[30-Mar-2021 10:32:08]  [pool production] pid 24884
script_filename = /var/www/production/current/restApi.php
[0x00007fae4ec14ef0] curl_exec() /var/www/production/releases/42/vendor/guzzlehttp/guzzle/src/Handler/CurlHandler.php:40
[0x00007fae4ec14e50] __invoke() /var/www/production/releases/42/vendor/guzzlehttp/guzzle/src/Handler/Proxy.php:28
[0x00007fae4ec14da0] GuzzleHttp\Handler\{closure}() /var/www/production/releases/42/vendor/guzzlehttp/guzzle/src/Handler/Proxy.php:51
[0x00007fae4ec14d00] GuzzleHttp\Handler\{closure}() /var/www/production/releases/42/vendor/guzzlehttp/guzzle/src/PrepareBodyMiddleware.php:66
[0x00007fae4ec14c20] __invoke() /var/www/production/releases/42/vendor/guzzlehttp/guzzle/src/Middleware.php:29
[0x00007fae4ec14b70] GuzzleHttp\{closure}() /var/www/production/releases/42/vendor/guzzlehttp/guzzle/src/RedirectMiddleware.php:70
[0x00007fae4ec14ad0] __invoke() /var/www/production/releases/42/vendor/guzzlehttp/guzzle/src/Middleware.php:59
[0x00007fae4ec14a40] GuzzleHttp\{closure}() /var/www/production/releases/42/vendor/guzzlehttp/guzzle/src/HandlerStack.php:71
[0x00007fae4ec149b0] __invoke() /var/www/production/releases/42/vendor/guzzlehttp/guzzle/src/Client.php:351
[0x00007fae4ec148a0] transfer() /var/www/production/releases/42/vendor/guzzlehttp/guzzle/src/Client.php:162
[0x00007fae4ec147c0] requestAsync() /var/www/production/releases/42/vendor/guzzlehttp/guzzle/src/Client.php:182
[0x00007fae4ec14730] request() /var/www/production/releases/42/vendor/guzzlehttp/guzzle/src/Client.php:95
[0x00007fae4ec14660] __call() /var/www/production/releases/42/src/Lib/WebSocketConnection.php:28
[0x00007fae4ec145d0] post() /var/www/production/releases/42/src/Lib/WebSocketConnection.php:37
[0x00007fae4ec14510] sendSock() /var/www/production/releases/42/src/Modules/Bell/BellGateway.php:218
[0x00007fae4ec144a0] updateFoodsaverClient() /var/www/production/releases/42/src/Modules/Bell/BellGateway.php:181
[0x00007fae4ec14400] delBellForFoodsaver() /var/www/production/releases/42/src/RestApi/BellRestController.php:105
[0x00007fae4ec14360] deleteBellAction() /var/www/production/releases/42/vendor/symfony/http-kernel/HttpKernel.php:157
[0x00007fae4ec14280] handleRaw() /var/www/production/releases/42/vendor/symfony/http-kernel/HttpKernel.php:79
[0x00007fae4ec141d0] handle() /var/www/production/releases/42/vendor/symfony/http-kernel/Kernel.php:195

aaah, apparently the calls to our websocket chatserver take ages.

let’s deactivate them for now in src/Lib/WebSocketConnection.php, and tada🎉 foodsharing.de runs smoothly again!

Manual request confirmes that the request runs forever: curl -v http://127.0.0.1:1338/users/1/is-online

Chatserver

a look into its log yields

$ journalctl -efu fs-chatserver
 error: Error: This socket has been ended by the other party                                                                                                            
     at Socket.writeAfterFIN [as write] (net.js:455:14)                                                                                                                 
     at /var/www/production/releases/31/chat/node_modules/tedis/build/core/base.js:83:26                                                                                
     at new Promise (<anonymous>)
     at Tedis.Base.command (/var/www/production/releases/31/chat/node_modules/tedis/build/core/base.js:78:16)                                                           
     at SessionIdProvider.fetchSessionIdsForUser (/var/www/production/releases/31/chat/src/SessionIdProvider.ts:24:43)                                                  
     at runMicrotasks (<anonymous>)
     at processTicksAndRejections (internal/process/task_queues.js:97:5)                                                                                                
     at RestController.userIsConnected (/var/www/production/releases/31/chat/src/RestController.ts:26:28) {                                                             
   code: 'EPIPE'
 }

okay, lets debug this! whats happening in /var/www/production/releases/31/chat/src/SessionIdProvider.ts? wait the file doesn’t exist? we are already at release 42, but the chat server still runs on 31!

Apparently it might be a known bug of tedis, the redis js library we use: https://github.com/silkjs/tedis/issues/49

because I had no idea, how to analyze the state further and the error might be already solved in the newest release: I did a systemctl restart fs-chatserver and the chatserver responses properly.

… at least for now. But that the tedis bug led to foodsharing.de being down included a chain of issues we should solve soon:

Issues

• Tedis can become unusable: tedis#49
• Chatserver just throws an error to the console, but doesn’t respond to the running http request: foodsharing#1068
• No timeout for the chatserver requests from PHP: foodsharing#1069
• No timeout for php requests: dragonfruit-ansible#6

the combination of each single issue was causing the outage.

additionally findings

• No monitoring for the chatserver: dragonfruit-ansible#7
• Chatserver should be restarted after deployments: foodsharing#1070

Thanks to ansible, cleaning up all the mess due to the fiddling with settings is quite an easy task, but I will rather run the playbook tonight - who knows what unexpected side effects it will have :D

Blog post about the Hackweekend August 2020 - a review

Hotfix

There was a hotfix in June which solved multiple problems. Some of these were introduced in the last release or were longer lasting, pressuring issues.

We are sending quite a few emails compared to our sending frequency, thus it takes some time until they arrive. This does not only affect emails for notifications but also for registration and password changes. There were many requests for the support asking why the expected email wouldn’t arrive. The priority of these emails was changed, such that they will be sent before other kinds of emails.

If an email can’t be delivered, the corresponted adress gets added to a bounce list. We do not sent emails to these adresses. They now get a warning on their profile for being on the list with an explanation how to remove their adress from the list. There is also a more explicit explanation about the problem from the support in this article in German.

There was a bug which saved a false gender when registrating. This is fixed now.

New Team List

There is a new team list in progress for the stores. It is implementend in Vue.js. Thereby is list is now much more mobile friendly. If you clicked on a person in the list before on a smartphone, their number was dialed. If you wanted to use any other option like viewing their profile, you had to go back to the browser.

Furthermore are now those responsible for the store always on top of the list, even if they have a sleeping hat on. Thus they are found much faster now.

Moreover it is not marked anymore if a person was or is an ambassador for a region anymore. Before the same color was used for both. Such labels can also reinforce hierarchies, even though they should not be important in that context.

Internationalization

We have the first translations to English!

Before, there was a DIY system to embed texts in the foodsharing website. Now we follow standards, such that it is easier for new developers to start and it will be less effort to implement a language switch.

This means in more technical details that our project was adapted to the Symfony structure further. This includes a session variable in which the current language is saved and the file naming convention from Symfony. Thus we do not need our own translation helper and validation anymore, but can use Symfony directly.

The old translations are changed ongoingly.

Blog post about the Hackweek May 2020 - a review

[Felix] Before Hackweek, I wasn’t sure if I was going to participate, so unfortunately I didn’t engage in the preparation. This preparation started quite slow, but in the time before the Hackweek the program filled up with topics and initiated sessions. For me as a still-newcomer these gave the opportunity to listen, ask questions and learn.

[Kristijan] The Hackweek is a joyful event for me to experience many of the active people live. Unfortunately Corona made this difficult. So it was all the more pleasant that there was an “online Hackweek”. Sessions were held in videoconferences, so at least we could see each other and contributed to a group feeling and a “we”. A nice and productive atmosphere was created and it was valuable to get feedback and new ideas for implementation. There were also funny sessions on actually serious topics, which made us loosen up.

[Caluera] In the Hackweek we got a lot done, especially things that would otherwise get lost in everyday life. We also talked a lot about structures and made plans how we will deal with some topics.

[moffer] The Hackweek has made a lot of progress, for me especially social aspects: Talking live with some people you only deal with through Gitlab or Slack. I also found the whole atmosphere positive. There was a lot of discussion, so there wasn’t much time for hacking - unfortunately for me the time was limited. However, I can imagine that such an online format could take place more often, since the orga effort (and possibly financial expenditure) is manageable. I would welcome that.

[Chris] I was particularly enthusiastic about the sense of community despite the physical distance :) All in all, many exciting insights into very different areas, productive discussions and a user-oriented exchange, plus a flexible organization with more structure exactly where it was needed - I would definitely be happy about a continuation soon and hope for many new faces as well.
So, you readers out there: next time, just drop in without obligation, drop by at some of the sessions and maybe get directly involved. Hackweeks are a great opportunity to get to know the team and the way they work - also and especially if you don’t do any programming yourself!

​ ​ ​

It’s time for the next foodsharing Hackweek!

Because of the Corona measures, we’ll be meeting online.

When - April 25th to May 3rd, 2020

Where - Online: Jitsi, Slack, Mumble…

We will discuss, program, give lectures to each other, and make foodsharing better together.

You can also participate for a few hours, it is worth it regardless of your own technical knowledge. The Hackweek is for both supporters and developers.

Let’s do this. ​ Matthias and Tilmann in a former Hackweek

​ ​ ​ On 15.02.2020, a few people from the foodsharing IT department met in Bochum to continue working on the foodsharing website. Here are reports from some of the people present: ​

project objective

We had considered that we needed an app to improve the manageability of food baskets for all users of www.foodsharing.de In the long run, all foodsaver functions will be built on this basis without replacing the website. Advantages of a smartphone app are the “sensors” that come with it, such as camera, GPS and positioning. We have yet to focus on the development of the Apple (iOS) App.

This is what the chat currently looks like

foodsharing is finally Open Source!

What does that actually mean?

This means that our basic principle for food (of saving and sharing) is now applied to the platform itself. Anyone can now view, download and modify the foodsharing code in the GitLab repository. But don’t worry, it’s always about a copy of our site and if someone plays around with the foodsharing code at home, it has no direct effect on what happens on foodsharing.de. On the other hand, it is not difficult to actually make changes to our homepage. To do this, the changes made at home simply have to be sent back to the source and updated together with our development team. Maybe you start by correcting a spelling mistake; maybe a new community comes along and starts with the complete translation into another language. The code is now open to everyone and change suggestions can be uploaded at any time.

Most importantly, we’re now sure that our beautiful project won’t go to waste behind closed doors, but can be freely shared - and that’s what foodsharing is all about.

But that’s not all: As an open source project, we have new opportunities to be supported, because all the programming we do now is obviously charitable. First of all this will pay off for the developers themselves, as we will apply for open source licenses for ‚helpful programs that make the development work easier‘. In the longer term, however, we can also apply for funding that is available for open source projects.

The Hackweek in Wurzen was great! There even was a small celebration to celebrate Open Sourcing. For more detailed information about what’s going on in the development team, have a look at this detailed changelog entry.

Wanna join and collaborate?

Are you thinking about joining the volunteer team in their work with diverse tasks? Are you interested to try new things?
Here you can find our Devdocs with some of the tasks we need support for.

Den Beginn des Pfingstwochenendes haben sich Chandi und ich ausgesucht, um uns allen die Freude an der Benutzung der foodsharing-Plattform zurückzuholen: Wir ziehen auf einen schnelleren Server um. Die Geschichte dazu möchte ich euch an dieser Stelle erzählen. Dieser Beitrag entsteht während des Umzugs - einerseits in Prokrastinationspausen, andererseits in Zwangspausen, während ich auf irgendetwas warten muss :-)

Was viele vielleicht nicht wissen, ist, dass der Kern der foodsharing-Entwickler die Plattform nur sehr sporadisch nutzt. So kam es vor zwei Wochen, dass ich mal wieder auf foodsharing.de gegangen bin, um nachzuschauen, ob ein Bug dort bereits vorhanden war und ich mich dabei ziemlich genervt davon gefühlt habe, dass die Plattform extrem langsam ist. Wir wussten eigentlich schon, dass wir so langsam ziemlich am Limit unseres Servers sind, aber es selbst zu spüren, ist nochmal was anderes.

Kurzerhand habe ich mich daraufhin freundlich und zurückhaltend an unseren Server-Sponsor Manitu gewendet und nachgefragt, ob wir - u. U. auch mit Zuzahlung einer kleinen Summe - einen schnelleren Server bekommen können, da sich unsere Nutzerzahlen aber auch die Komplexität unserer Anwendung stetig weiterentwickeln.

Die Antwort kam nach wenigen Stunden vom Chef persönlich: Sehr gerne wird foodsharing weiter unterstützt. Ein Mitarbeiter schaut zeitnah mal, was sie uns aus dem Reste-Pool anbieten können. Meine Freude - und auch die im weiteren Team, mit dem ich die Nachricht schnell geteilt habe - war groß. Zwar wussten wir, dass wir mit Manitu als inhabergeführtem Unternehmen “Von Menschen für Menschen” einen guten Partner an der Hand haben, aber es ist wundervoll, auch nach so vielen Jahren weiterhin so eine Unterstützung und positive Kommunikation zu erfahren.

We held our second dedicated foodsharing hackweek at the start of July. The location was the same as our previous hackweek, in the lovely Kanthaus project.

Again, we were mostly the regular people (Matthias, Tilmann, and me), but Chandi also joined again with a pleasing burst of motivation, and we had a new contributor, Theo, come down from Berlin for a few days.

We got some really good things done, including:

• getting all site JavaScript moved over to the new webpack environment
• creating the first VueJS component
• adding the first RESTful API endpoint
• removing one whole layer of the database hierarchy
• a shiny new and sleek README.md page

Matthias and Tilmann ponder for a while

Theo Symfony-wrangling in vim

Issue tracker now in foodsharing project

Peter noticed, that gitlab supports private code with public issues. So here we go, we switched our foodsharing project to public and restricted the code access to accepted members.

Please use the issue tracker inside now.

Last week we finished our first ever dedicated foodsharing.de hackweek!

We tried out the new week long format last September at our foodsaving worldwide hackweek and found it gave us more time to focus on more substantial/abstract/architectural changes.

We were a small team - with me, Matthias, and Tilmann focused for the whole duration, with shorter visits from other people:

• Kristijan came and implemented the new communities overview pages with our new contributor Basti
• Jörg came to meet the dev team and have some discussions about data protection topics
• Chandi came and implemented a more secure password hashing algorithm (using Argon2i).
• Basti came and fixed some requested issues like not listing the work groups on the details page reachable through the team page.

Tilmann, Nick, and Matthias discussing some of the finer points of PHP

Matthias, Chandi, Kristijan, and Tilmann in the repurposed silent working office at kanthaus

Dear readers,

As we are progressing with the refactoring of foodsharing.de, we are creating the need for more management tasks to be executed at deploy time. For now, these are:

• Invalidating template cache
• Invalidating Dependency Injection container cache
• Install/update external php packages via composer

This is leading to a more and more inacceptable behaviour:

— UPDATE: Greensta continues to support us as before and we are not necessarily looking for a new solution here. If you’re still interested in helping out in this area, feel free to read more about what we do and then just get in touch via Slack on the #foodsharing-dev channel —

What’s going on with the emails at foodsharing?

Well, we want to send about 1 million of them a month. That’s not so easy.

Schön, dass du die foodsharing.de Entwicklung als Beta-Tester unterstützen magst! Damit du das sinnvoll tun kannst, lass mich dir kurz davon erzählen, wie die Entwicklung arbeitet:

Es gibt ein kleines Team von Entwicklern, welche in ihrer Freizeit mal mehr und mal weniger an der Entwicklung teilhaben. Die Entwickler versuchen einerseits, Fehler zu beheben und sind andererseits dabei, den Code so umzustrukturieren, damit er leichter les- und bearbeitbar ist. Zudem haben sie manchmal auch eine gute Idee, wie ihre eigene Arbeit (oder die von anderen) auf der Plattform vereinfacht werden kann. Diese setzen sie dann manchmal um, oder auch nicht (Dies nennt sich “Feature”). Dann gibt es die Kommunikation mit Nutzern der Plattform oder administrativen Stellen wie z.B. dem Vorstand: Von all diesen Stellen kommen viele viele Anfragen, die aufgrund gemachter Annahmen oder enthaltener Informationen in der Regel nicht attraktiv für Entwickler zu bearbeiten sind. Deshalb werden sie meistens einfach ignoriert. Wenn pro Woche in der Summe 30 Stunden in die Entwicklung von foodsharing.de investiert werden (1-20 Stunden pro Person), wird davon einiges für interne Kommunikation benötigt. Die reine Entwicklungszeit beträgt nurnoch wenige Stunden pro Woche. Soll davon nun auch noch etwas zur individuellen Kommunikation nach außen benutzt werden, so würden wir beim Stillstand ankommen.

Our first release using the new approach, yay!

This release contains some important structural improvements, perhaps most significantly, we are now using composer for dependencies where possible, and running on php7.

There are also a good number of smaller, but visible changes to the site, mostly bugfixes, but a few new features too.

Many many thanks to all the contributors that made this possible (in order of appearance in the changelog):

• @valentin.unicorn
• @nicksellen
• @NerdyProjects
• @k.miklobusec
• @peter.toennies
• @raphaelw
• @tiltec

Nick and Matthias deploying the new release

A nice agency has created a campaign for foodsharing which means we can spread the message about food waste prevention via social media, posters, and bags! How cool!

The problem is that the campaign will not really explain the whole concept of foodsharing, but just direct people to the homepage, which currently is really lacking a general overview of how it all works.

We actually have a new homepage concept ready, but the task is to incorporate it into the existing foodsharing.de homepage.

Hi there, new interested developer. This post should help you to get started in foodsharing development and answer your most urgent questions :-)

For general participation in development, please join our slack channel #foodsharing-dev on the yunity slack.

I started getting involved in the foodsharing software last October, I originally wrote: For now the task is breathe life into the development again.

It has been progressing at a pretty glacial pace since then (but progress is progress right?) but recently there has been more interest in finding a clearer way forward from here. I get the feeling people are thinking the software is a lost cause by now.

Personally, my frustration has increased as I see a ever growing list of issues in gitlab, not much clarity around switching to laravel, what to do with foodsharing light, how to progress open sourcing… etc.

For some reason unknown to me, I cannot bear to give up!

Wie sieht es mit der Weiterentwicklung von foodsharing.de aus? Wer ist denn aktuell daran beteiligt?

Zunächst einmal als Übersicht eine Liste von Menschen, die aktuell an der Foodsharing.de-Entwicklung beteiligt sind.

The dust has just settled from our small hackathon this weekend.

We welcomed the return of the original developer of foodsharing.de Raphael Wintrich having successfully applied for prototypefund.de funding. The rest of the small team being me and Matthias Larisch.

Raphael and Matthias stare at a computer screen

It’s no secret that development progress has been slow and we all sometimes wonder why we continue on the project, especially when we realised none of us actually use the website ;)

However, the motivation to hold a hackathon came from Raphaels return to the project and my return to Berlin after some months travelling. I am still fully convinced this is a great platform, with a great community behind it, and without a doubt deserves more attention from the developer community.

We have a new year now and seems a good time for a little review of progress.

Watching our attempt to kickstart the development of foodsharing.de has been fascinating for me. This stuff is tricky, and there is no guarantee of success.

The starting premise was that the project is very worthwhile with a great community of foodsavers and there are no viable alternative software platforms. It’s too good to abandon!

We achieved some key things:

• docker based development environment setup
• tests
• CI system to build/test on each push
• a clearer path for contributors to join (slack channel, public gitlab group)
• new contributors
• 45 closed issues
• 82 merged merge requests

Right now though, development has slowed again. This is OK, projects move in many cycles of rise and fall. If we give up as soon as things get tricky we cannot achieve much.

Lets dig into some of the difficulties…

Good evening, dear blog readers!

For a few months now, we still had a server available on which Kristijan wanted to make some Wiki tests for the internationalization. But it wasn’t used in the end and therefore available for rescue.

As we are still in the process of getting our tools and environment set up, this is a nice opportunity for me to as well look into gitlab CI and this blog system.

If you may not have noticed, this blog is maintained in a gitlab repository , runs on the Jekyll static site generator and is written in markdown.

A lot has been happening with foodsharing development lately and we’d love to share it more widely and publicly now.

We write from our developer perspective, so it will get technical at times, but should hopefully be interesting for anyone involved with foodsharing.