Seit unsere Tochter klettern und laufen kann, tut sie das mit großem Vergnügen und steigt auch schon mal allein aus dem Bett aus, wenn sie keine Lust mehr auf Mittagsschlaf hat. Aus dem elterlichen Bett wohlgemerkt, denn für ihr Kinderbett mit den Gitterstäben ist sie offenbar zu freiheitsliebend Es kommt also vor, dass sie im Schlafzimmer umherläuft, ohne das wir das akustisch übers Babyfon mitbekommen. Wenn das Babyfon doch nur eine Kamera hätte …
Doch halt! Hier liegt doch noch ein ungenutzter Raspberry Pi der ersten Generation herum, einen USB-WLAN-Stick habe ich auch noch und ein paar alte Webcams - von denen leider keine so richtig unter Raspian funktionieren mag. Eine kurze Recherche ergibt, dass die günstigste lauffähige Alternative wohl eine Playstation Eye ist. Geklickt, geliefert, angesteckt: Funktioniert!
Die Babycam steht auf dem Schrank, der Karton enthält den Raspberry Pi
Ich hatte kürzlich mit einem Projekt auf Basis des Flow Frameworks zu tun. Zu den Besonderheiten dieses PHP-Frameworks gehört unter anderem die Unterstützung von Aspect-Oriented Programming (AOP), mithilfe dessen sich generische Funktionalitäten relativ sauber über verschiedene Klassen hinweg verwenden lassen (cross-cutting concerns). Wie das funktioniert, ist in der Dokumentation ausführlich beschrieben.
Zu diesem Zweck erstellt Flow automatisch Proxy-Klassen, welche die Original-Klassen erweitern und die nicht zuletzt aus Performance-Gründen gecachet werden. Dabei werden gegebenenfalls Aspekte, Pointcuts oder Advices in Klassen "eingewoben". Die Applikation verwendet die auf diese Weise generierten Klassen, in der Entwicklung wird aber weiterhin nur mit den Originalen gearbeitet.
Ein bedeutender Nachteil dieser Vorgehensweise ist, dass Debugging - z.B. mit XDebug - nicht mehr ohne Weiteres möglich ist, denn die IDE kennt nur die Original-Klassen, nicht aber die dynamisch erstellten Proxy-Klassen. Um dieses Problem zu lösen, wurde flow-debugproxy geschreiben, ein Flow Framework Debug-Proxy for XDebug in Go, der die Proxy-Klassen auf die Original-Klassen "mappt".
Da dieser Proxy nicht ganz trivial zu installieren ist, habe ich hier eine kurze Anleitung aufgeschrieben, die in dem genannten Projekt funktioniert hat (und mir nebenbei eine Kiste Bier eingebracht hat ):
Als Christian und ich Anfang 2010 das erste Meetup der PHP User Group Rheinhessen organisierten, ahnten wir nicht, dass wir über sieben Jahre später das 50. Treffen anstehen würde. Um diese Erfolgsgeschichte gebührend zu feiern, wollen wir das Meetup Nr. 50 in etwas anderer Form abhalten: Im Mainzer Volkspark als PHPBBQ!
PHPBBQ 2017 bedeutet, dass sich PHP-Entwickler am Samstag, dem 1. Juli 2017, zum gemeinsamen Grillen, Fachsimpeln und Entspannen treffen. Damit diesmal auch Familie, Kinder oder PartnerInnen dabei sein können, haben wir ganz bewusst einen Samstag ausgewählt und wollen schon am frühen Nachmittag starten.
In den letzten Jahren hat immer wieder die Frankfurter PHPUG zum Grillen eingeladen, zuletzt 2016 im Licht- und Luftbad Riederwald. Da die Frankfurter Kollegen es dieses Jahr aus Gründen™ nicht geschafft haben, das PHPBBQ zu veranstalten, übernehmen wir in Absprache und mit Unterstützung der dortigen Community und laden hiermit explizit auch alle Frankfurter PHP-Entwickler in die rheinland-pfälzische Landeshauptstadt ein!
Wenn ihr kommen wollt, meldet euch bitte entweder auf Xing oder auf Meetup an, damit wir besser planen können. Vielen Dank, wir sehen uns beim Grillen!
Weitere aktuelle Infos zum PHPBBQ 2017 findet ihr im Wiki und auf Twitter.
Diese Woche war ich in Nürnberg auf dem Developer Camp 2017, das im Kulturzentrum Z-Bau stattfand. Die Location stellte sich als perfekt für ein Barcamp heraus. Die Organisation des Camps klappte wie am Schnürchen, das WLAN war schnell und stabil, die Verpflegung super. Um es gleich vorweg zu sagen: Das Camp war eine runde und gelungene Sache! Vielen, vielen Dank an das Orga-Team von Mayflower und die Sponsoren!
Die "Selbsthilfegruppe User Group-Organisatoren" tagt auf dem #devcamp17 unter dem Sonnenschirm (Foto von Tobias Merkl)
Auch wenn ich nur an einem der beiden Camp-Tage teilnehmen konnte, habe ich viel Spannendes und Neues gelernt, interessante Gespräche geführt und Kontakte knüpfen können. Hier meine kurze Zusammenfassung einiger Sessions und Themen.
Ihr habt vielleicht schon vom "Citizen Science"-Projekt Luftdaten.info gehört, das vom OK Lab Stuttgart initiiert worden ist. Dessen Ziel ist es, die Feinstaubbelastung in Stuttgart unabhängig durch Freiwillige zu messen, zu visualisieren, und so Maßnahmen für eine bessere Luftqualität mit Offenen Daten zu unterfüttern. Mehr dazu auch in diesem Beitrag in DRadio Wissen (das nebenbei bald Deutschlandfunk Nova heißen wird).
NodeMCU ESP8266, Temperatursensor DHT22 und Feinstaubsensor SDS011
Ursprünglich sollte nur die Feinstaubbelastung der schwäbischen Metropole gemessen werden, aber mittlerweile sind Sensoren in ganz Deutschland und sogar in anderen Ländern auf der Luftdaten-Karte verzeichnet. Auch mein Sensor (ID 1777) misst seit ein paar Tagen die Feinstaubbelastung und ist damit einer von momentan vier Sensoren in Wiesbaden.
Als ich das erste Mal von Luftdaten.info gehört hatte, war ich gleich begeistert und ein eigener Sensor stand sofort auf meiner Todo-Liste. Diese Woche war es endlich so weit: Alle benötigten Bauteile waren (z.T. nach wochenlanger Reise aus China, der Feinstaubsensor ist hierzulande kaum erhältlich) eingetroffen, und ich hatte etwas Zeit zum Basteln.