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.

Gut organisiert Lebensmittel retten und gemeinsam die Zukunft organisieren – dafür brauchen wir jetzt euch!

Damit unsere gemeinsame Plattform, welche die Basis für eure Lebensmittelrettungen ist, weiterleben kann, brauchen wir euch und eure Erfahrungen.

Doch bevor wir dazu kommen, was wir von euch erwarten, möchten wir euch unsere Herausforderungen kurz darstellen.

Es ist Zeit für die nächste foodsharing Hackweek!

Es ist Zeit für das nächste foodsharing Hackweekend!

Aufgrund der Corona-Maßnahmen werden wir sie online durchführen.

Wann - 14. Januar bis 16. Januar 2022

Wo - Online: BigBlueButton (ohne Anmeldung möglich), Slack.

Wir werden diskutieren, programmieren, gegenseitig Vorträge anbieten, und foodsharing gemeinsam besser machen.

Man kann auch für ein paar Stunden dabei sein, es lohnt sich unabhängig von den eigenen technischen Vorkenntnissen. Das hackweekend ist sowohl für Unterstützer*innen als auch für Entwickler*innen.

Sei dabei!

Matthias and Tilmann in einer früheren 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

Blogpost über das Hackweekend im Herbst 2020 - ein Rückblick

Hotfix

Mitte Juni gab es einen Hotfix. Dabei wurden mehrere Probleme behoben, die teilweise beim letzten Release mit reinkamen oder schon länger bestanden und immer dringlicher wurden. Da wir ein relativ hohes E-Mail-Aufkommen im Vergleich zu der uns möglichen Sendefrequenz haben, dauert es immer eine Weile, bis E-Mails ankommen. Dadurch gab es recht viele Supportanfragen, dass E-Mails zu vergessenen Passwörtern, zur Änderung von E-Mail-Adressen und zur Registrierung nicht ankämen. Diese haben nun eine höhere Priorität, sodass diese nun schneller als andere E-Mail-Benachrichtigungen ankommen.

Wenn eine E-Mail von foodsharing nicht zugestellt werden kann, kommt die zugehörige Adresse auf die Bounce Liste. An E-Mail-Adressen auf dieser Liste werden keine Mails mehr versandt. Seit dem Hotfix wird nun eine Warnung auf dem Profil angezeigt, wenn dies so ist, mit einer Erklärung, wie das geändert werden kann. Es gibt auch beim Support jetzt einen Artikel, in dem das ganze noch mal genauer erläutert ist.

Es kam zu einem Bug, wo das bei der Registrierung angegebene Geschlecht falsch abgespeichert wurde. Dieser ist nun behoben.

Neue Teamliste

In den Betrieben ist eine neue Teamliste in Arbeit. Diese wurde in Vue.js neuimplementiert. Damit ist die Liste nun deutlich mobile-freundlicher. Zuvor war es so, dass es beim Klicken auf eine Person in der Liste eine direkte Weiterleitung gab, sodass die Nummer gewählt wurde. Wollte man die anderen Menüoptionen nutzen, musste man erst zurück zum Browser.

Desweiteren sind nun die Betriebsverantwortlichen immer oben in der Liste, selbst wenn sie eine Schlafmütze aufhaben. Damit sind diese deutlich schneller in der Liste auffindbar. Außerdem wird nicht mehr farblich markiert, ob eine Person Botschafter:in ist oder war, für das vorher die Markierung die selbe war. Außerdem können solche Kennzeichnung Hierarchien verstärken, obwohl diese im Kontext der Abholungen keine Rolle spielen sollten.

Internationalisierung

Es gibt die ersten Übersetzungen ins Englische!

Bislang gab es ein selbstgebautes System, welches Texte in die Webseite einband. Durch Anpassung an Standards wird es für neue Entwickler nun einfacher, sich einzufinden, und es ist weniger Aufwand, einen Umschaltbutton für andere Sprachen einzurichten.

Technisch bedeutet dies, dass unser Projekt weiter an die Symfonystandardstruktur angepasst wurde. Das beinhaltet eine Sitzungsvariable, die die aktuelle Sprache speichert, und die von Symfony vorgegebene Dateibenennung. Dadurch brauchen wir nun keine eigenen Übersetzunghelfer und -validierer mehr, sondern können direkt Symfony nutzen. Stück für Stück werden weiterhin die alten Übersetzungen angepasst.

Blogpost über die Hackweek Mai 2020 - ein Rückblick

[Felix] Vor der Hackweek war ich unsicher, ob ich mich beteilige und habe mich daher leider nicht an der Vorbereitung beteiligt. Diese Vorbereitung lief erst rech schleppend an, aber in der Zeit kurz vor der Hackweek füllte sich das Programm mit Themen und initiierten Sessions. Für mich als Immer-noch-Neuling haben diese die Möglichkeit gegeben, zuzuhören, Fragen zu stellen und damit zu lernen.

[Kristijan] Die Hackweek ist für mich ein freudiges Ereignis um viele der aktiven Namen auch mal live zu erleben. Corona hat dies leider erschwert. Umso erfreulicher war es, das es eine “online Hackweek” gab. Sessions wurden in Videokonferenzen abgehalten, so konnte sich zumindest mal gesehen werden und haben wesentlich zu einem Gruppengefühl und einem “wir” beigetragen. Es entstand eine schön produktive Atmosphäre und es war wertvoll Feedback und neue Ideen für Umsetzungen zu erhalten. Es gab auch lustige Sessions zu eigentlich ernsten Themen, die damit aufgelockert wurden.

[Caluera] In der Hackweek haben wir richtig viel erledigt bekommen, gerade auch Sachen, die sonst im Alltag eher untergehen. Wir haben viel auch über Strukturen gesprochen und Planungen gemacht, wie wir mit manchen Themen umgehen werden.

[moffer] Die Hackweek hat einiges vorangebracht, für mich vor allem auch soziale Aspekte: Mit einigen Leuten quasi live reden, mit denen man sonst nur über Gitlab oder Slack zu tun hat. Auch fand ich die gesamte Stimmung positiv. Es wurde reichlich diskutiert, wodurch zum Hacken gar nicht so viel Zeit blieb - bei mir war leider durch private Gründe die Zeit auch recht begrenzt. Ich kann mir jedoch vorstellen, dass so ein Onlineformat auch öfters stattfinden kann, da sich der Orga-Aufwand (und evtl finanzieller Aufwand) in Grenzen hält. Ich würde das begrüßen.

[Chris] Besonders begeistert hat mich das Gemeinschafts-Gefühl trotz der räumlichen Entfernung :) Insgesamt viele spannende Einblicke in ganz unterschiedliche Bereiche, produktive Diskussionen und ein am Nutzer orientierter Austausch, dazu eine flexible Organisation mit mehr Struktur genau da, wo es nötig war - ich würde mich über eine baldige Wiederholung definitiv freuen und hoffe auf viele auch neue Gesichter.
Also, ihr Leser da draußen: Schaut einfach beim nächsten Mal unverbindlich rein, bei einigen Sessions vorbei und bringt euch vielleicht direkt ein. Hackweeks sind nämlich eine super Gelegenheit, das Team und die Arbeitsweise kennenzulernen - auch und insbesondere dann, wenn ihr nicht selbst mit programmiert!

Es ist Zeit für die nächste foodsharing Hackweek!

Aufgrund der Corona-Maßnahmen werden wir sie online durchführen.

Wann - 25. April bis 3. Mai 2020

Wo - Online: Jitsi, Slack, Mumble, …

Wir werden diskutieren, programmieren, gegenseitig Vorträge anbieten, und foodsharing gemeinsam besser machen.

Man kann auch für ein paar Stunden dabei sein, es lohnt sich unabhängig von den eigenen technischen Vorkenntnissen. Die hackweek ist sowohl für Unterstützer*innen als auch für Entwickler*innen.

Sei dabei!

Matthias and Tilmann in einer früheren Hackweek

Am 15.02.2020 haben sich einige aus der foodsharing IT in Bochum getroffen, um an der foodsharing Webseite weiterzuarbeiten. Hier sind Berichte von einem Teil der Anwesenden:

Projektziel

Wir hatten uns überlegt, dass wir eine App brauchen, um die Handhabbarkeit von Essenskörben für alle Benutzer*innen von www.foodsharing.de zu verbessern. Langfristig sollen auf diese Basis alle foodsaver-Funktionen aufgebaut werden, ohne die Webseite zu ersetzen. Vorteile einer Smartphone-App sind die vorhandenen “Sensoren” wie Kamera, GPS und Ortung. Dem gegenüber nachrangig und doch im Blick ist die Entwicklung der Apple (iOS) App.

So sieht der Chat derzeit aus

foodsharing ist endlich Open Source!

Aber was bedeutet das eigentlich?

Das bedeutet, dass unser grundlegendes Prinzip vom Retten und Teilen jetzt auch auf die Plattform selbst angewandt ist. JedeR kann jetzt im Repository auf GitLab den Code von foodsharing. einsehen, runterladen und verändern. Aber keine Sorge, dabei geht es immer nur um eine Kopie unserer Seite und wenn jemand bei sich zuhause am Rechner am foodsharing-Code rumspielt, dann hat das natürlich keinerlei direkte Auswirkungen auf das, was auf foodsharing.de passiert. Auf der anderen Seite ist es allerdings auch nicht schwierig, tatsächlich Änderungen an unserer Homepage vorzunehmen. Dafür müssen die zuhause gemachten Änderungen einfach nur zur Quelle zurückgeschickt und gemeinsam mit unserem Entwicklerteam eingepflegt werden. Vielleicht beginnt man mal mit der Korrektur eines Rechtschreibfehlers; vielleicht kommt aber auch mal eine neue Community und beginnt mit der kompletten Übersetzung in eine andere Sprache. Der Code ist jetzt für alle offen und Änderungsvorschläge können jederzeit hochgeladen werden.

Vor allem aber sind wir jetzt sicher, dass unser schönes Projekt nicht hinter verschlossenen Türen versauert, sondern dass es frei geteilt werden kann - und das ist es doch, worum es bei foodsharing geht.

Das ist aber noch nicht alles: Als Open Source Projekt haben wir neue Möglichkeiten gefördert zu werden, denn alles was wir jetzt an Programmierarbeit tun ist offensichtlich gemeinnützig. Als erstes wird sich das für die EntwicklerInnen selbst auszahlen, da wir Open Source Lizenzen für hilfreiche Programme, die die Entwicklungsarbeit einfacher machen, beantragen werden. Längerfristig können wir uns aber auch um Fördergelder bewerben, die für Open Source Projekte zur Verfügung stehen.

Die Hackweek in Wurzen ist noch nicht komplett vorbei, und die Laune ist nach wie vor bestens! Vorgestern Abend gab es eine kleine Feier um das Open Sourcing gebührend zu zelebrieren, und für detailliertere Infos zu dem, was sonst so im Entwicklerteam los ist, schaut in diesen ausführlichen Changelog-Entry.

Lust, dabei zu sein?

Hat dich dieser Beitrag angefixt, auch Teil eines ehrenamtlich arbeitenden Teams mit diversesten Aufgaben und dem Interesse, einfach mal neue Dinge ausprobieren zu können, zu werden?
Hier findest du unsere Devdocs, mit einem Teil der Aufgaben, bei denen wir noch nach Unterstützung suchen.

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 nun mit im foodsharing Projekt

Peter hat festgestellt, dass Gitlab es auch unterstützt, einen öffentlichen Issue tracker mit geschlossenem Repository zu verbinden. Also haben wir das foodsharing Projekt jetzt öffentlich gemacht und lediglich den Zugriff auf den Sourcecode eingeschränkt.

Bitte nutzt jetzt den Issue tracker im foodsharing Repository.

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 unterstützt uns weiterhin wie bisher und wir suchen hier nicht mehr unbedingt nach einer neuen Lösung. Falls du dennoch interessiert bist, in diesem Bereich mitzuhelfen, lies gern genauer, was wir machen und dann melde dich einfach über Slack im Kanal #foodsharing-dev —

Was ist da los, mit den E-Mails bei foodsharing?

Nun, wir wollen ungefähr 1 Millionen davon im Monat versenden. Das ist garnicht so einfach.

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

Eine nette Agentur hat eine Kampagne für foodsharing entwickelt. Damit können wir den Aufruf gegen die Lebensmittelverschwendung nun über soziale Netzwerke, Werbetafeln und Taschen verbreiten! Wie cool!

Das Problem ist, dass die Kampagne nicht das ganze Konzept von foodsharing erklären wird, aber die Menschen direkt auf die Homepage leitet, welche derzeit keinen guten Überblick darüber gibt, wie genau das bei foodsharing eigentlich alles funktioniert.

Es gibt bereits ein neues Konzept für eine Startseite, die Aufgabe ist nun, dies in die foodsharing.de Webseite zu integrieren.

Hey, interessierter neuer Entwickler. Mit diesem Beitrag möchte ich dich dabei unterstützen, in die Entwicklung einzusteigen und deine dringensten Fragen beantworten.

Um mit uns zusammen zu entwickeln, tritt bitte unserem Slack-Kanal #foodsharing-dev im yunity slack bei.

Seit letztem Oktober habe ich jetzt mit der foodsharing Software zu tun. Am Anfang schrieb ich: Diese Seite verdient mehr Liebe von Entwicklern.

Seitdem waren die Fortschritte eher schwerfällig (trotzdem sind Fortschritte immernoch Forschritte, nicht wahr?), aber seit Kurzem gibt es wieder mehr Interesse daran einen klareren Weg nach vorn zu finden. Ich bekomme inzwischen das Gefühl, dass die Leute denken die Software wäre sowieso nicht mehr zu retten.

Durch die immer länger werdende Issue-Liste auf Gitlab, die Unklarheit ob jetzt zu Laravel gewechselt werden soll oder nicht, was es überhaupt mit foodsharing light auf sich hat und wie wir das Opensourcing vorantreiben können, ist meine persönliche Frustration auf jeden Fall gewachsen.

Aus irgendeinem Grund, der mir selbst nicht ganz klar ist, kann ich aber einfach nicht aufgeben!

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.

Die Staubwolken unseres kleinen Hackathons am Wochenende haben sich gerade gelichtet.

Wir begrüßten die Rückkehr des ursprünglichen Entwicklers von foodsharing.de, Raphael Wintrich, mit seiner erfolgreichen Bewerbung bei der prototypefund.de Förderung. Die anderen Teilnehmer in unserem kleinen Team sind ich sowie Matthias Larisch.

Raphael und Matthias schauen auf einen Computerbildschirm

Es ist kein Geheimnis, dass der Entwicklungsfortschritt langsam war und wir uns alle manchmal fragen, warum wir überhaupt an dem Projekt weiterarbeiten, gerade wenn wir feststellen, dass keiner von uns die Website überhaupt benutzt ;)

Wie dem auch sei, der Antrieb einen Hackathon durchzuführen entstand durch Raphaels Rückkehr zum Projekt und meiner Rückkehr nach Berlin nach einigen Monaten Reisen. Ich bin immernoch vollkommen überzeugt, dass es sich um eine großartige Plattform mit einer großartigen Community dahinter handelt, welche ohne Zweifel mehr Aufmerksamkeit aus der Entwickler Community verdient.

Ein neues Jahr hat begonnen und deshalb scheint es eine gute Zeit für eine kleine Übersicht über die neuesten Entwicklungen zu sein.

Unseren Versuch, das Development von foodsharing.de anzukurbeln, zu beobachten war faszinierend für mich. Solche Dinge sind heikel und es gibt keine Erfolgsgarantie.

Die Anfangsbedingung war, dass das Projekt den Aufwand wert ist, eine großartige Community von Foodsavern hat und, dass es keine brauchbaren alternativen Software Plattformen gibt. Es ist einfach zu gut, um es aufzugeben!

Wir haben ein paar Schlüsselerfolge erzielt:

• Einrichtung einer docker-basierten Entwicklungsumgebung
• Tests
• CI-System, um die Anwendung es bei jedem Push zu bauen/zu testen
• Einen übersichtlicheren Weg für Mitwirkende, um sich anzuschließen
  (Slack Channel, Öffentliche Gitlab Gruppe)
• Neue Mitwirkende
• 45 abgeschlossene Tickets
• 82 zusammengeführte Merge-Requests (Änderungsvorschläge)

Im Moment ist die Entwicklung allerdings wieder abgeschwächt. Das ist in Ordnung, Projekte bewegen sich in vielen Zyklen von Aufs und Abs. Wenn wir aufgeben, sobald die Dinge schwierig werden, können wir nicht viel erreichen.

Lasst uns in ein paar Schwierigkeiten wühlen.

Guten Abend, liebe Blog-Leser!

Seit ein paar Monaten hatten wir nun noch einen Server herumliegen, auf dem Kristijan ein paar Wiki-Versuche für die Internationalisierung vor hatte, der aber im Endeffekt nicht genutzt wurde und somit zur Rettung frei stand.

Da wir gerade noch dabei sind, unsere Werkzeuge und Umgebung einzurichten, ist das für mich eine gute Gelegenheit gitlab CI und dieses Blog-System auch genauer anzuschauen.

Falls ihr es noch nicht bemerkt habt: dieser Blog wird in einem gitlab repository verwaltet, mittels des Jekyll Generators erzeugt und ist in Markdown geschrieben.

Vieles ist in letzter Zeit passiert rund um die Entwicklung der foodsharing Plattform und wir möchten das nun auch einem breiteren Publikum zugänglich machen.

Wir schreiben aus unserer Entwickler-Perspektive, es wird also manchmal etwas technisch werden. Nichtsdestotrotz sollte dies interessant sein für jede in foodsharing involvierte Person.