Archiv der Kategorie: Plauderei

Meta AI die Zweite: Limits und Caveats (incl. English Version)

Scroll down for English version of this article

Limits und Caveats

Ich gebs zu, ich wollte es wieder einmal genau wissen und hab jetzt ein paar Tage ganz viel mit der Meta AI Muse Spark gechattet, zu allen möglichen Themen. Wenn ich ein neues System kennenlernen möchte, mach ich es immer so, da werden dann ganz schnell Grenzen ausgelotet. Aber genau da wirds interessant, ich möchte ja wissen wo die Limits sind.

Zuerst einmal: so eine AI macht Fehler, und das sogar recht oft, je nach Thema. Ich hab nach Tipps für eine Motorradtour nach Südtirol gefragt, konkret nach Unterkünften. Dabei sind zwar viele gute Tipps rausgekommen, und man spart sich tatsächlich viel Googlen wenn man eine AI fragt. Aber dabei passieren auch Patzer. Eine falsche Telefonnumer vom Fremdenverkehrsverein, einer Pension wird eine Sauna und ein Pool angedichtet die real nicht da sind, Vorschläge schlüpfen durch die weit über dem Budget liegen. Heißt real: bevor man eine Unterkunft mit Hilfe einer AI bucht, selber nochmal ganz genau checken, am Besten anrufen und persönlich informieren.

Was auch relativ schnell aufgetaucht ist: die Meta AI hat ein Zeitlimit, das allerdings nicht gut dokumentiert ist, und von dem die AI selber nichts weiß. Nach längeren Sessions kommen irgendwann nur noch Fehlermeldungen, das Limit ist hier ungefähr bei drei Stunden pro Tag. Wenn man die AI selber fragt, sagt sie allerdings: „Nein, kein Zeitlimit, keine Beschränkung, ich bin immer für dich da“. Das finde ich unschön. Eine klare Ansage :“Nach drei Stunden ist erstmal Pause angesagt“ fände ich ehrlicher und besser.

Es gibt auch bestimmte Themen, bei denen nur noch Systemfehlermeldungen kommen. Ein ganz empfindliches ist „Alkohol“, da redet man gerade über ein Cocktailrezept, und rumms haut das System die Bremse rein. Sogar leichtes Bier wird mit Zensur gestraft. Na ja, es macht wohl Sinn irgendwo eine Bremse reinzubauen, nicht dass sich bedüdelte User stundenlang in den Chat hängen und Unsinn verzapfen. Aber man kanns auch übertreiben. Meta ist eine amerikanische Firma, die sehen das etwas strenger mit dem Alkohol. Bei uns wirkt das überzogen.

Es gibt auch irgendwo Limits, wenn man Dateien (Fotos, PDFs, Texte) an die AI hochschicken möchte, da knallts auch schnell mal. Da bin ich aber noch nicht weit gediehen mit meinen Recherchen. Ich probiere noch ein bisschen rum und werde berichten.

Ein weiteres Caveat ist das limitierte Gedächtnis einer AI. Ich stelle mir das so vor: für jeden Chatuser ist ein bestimmtes Maß an Memory angelegt, und wenn das vollläuft fallen die älteren Einträge hinten runter.Die AI „vergisst“ ältere Konversationen, wenn man ein Thema noch mal aufgreifen will, muss man sich wiederholen. Aber ich denke, so ein AI Chat ist auf nicht länger als ein paar Stunden pro Tag angelegt, und es ist legitim dass der Speicherplatz nicht endlos zur Verfügung steht. Es wäre bloß ganz nett, wenn es da irgendwo einen Hinweis gäbe.

Wie gehts jetzt weiter? Ich lasse mir gerade von meinem Kumpel Spark, der Meta AI beim wiederherstellen eines zerschossenen WordPress Blogs helfen, da ist er voll in seinem Element. Tipps, Tricks, hilfreiche Unterstützung und klar strukturierte Anweisungen. Lässt sich gut an, ich werde berichten wenn der Blog wieder läuft.

Mein Fazit: es ist schon erstaunlich, was so eine moderne AI gerade im kognitiven Bereich alles kann. Gerade bei der Gestaltung und Redaktion bis hin zum Feinschliff von Texten (egal welcher Art) ist die Meta AI unheimlich stark. Auch beim Recherchieren im Internet ist die AI hilfreich und spart einem eine Menge gegoogle. Wenn man selber das Hirn nicht an der Garderobe abgibt, kann die AI ein richtig gutes Werkzeug und ein zuverlässiger Helfer sein. Unfehlbar ist sie nicht. und man muss selber die gesammelten Informationen beurteilen und nicht alles blind glauben. Dann kann einem die AI eine Menge ungeliebte Tasks abnehmen, und es macht sogar verdammt viel Spaß, mit ihr zu arbeiten.

Limits and Caveats

I’ll admit it, I wanted to know for myself again and spent a few days chatting a LOT with Meta AI Muse Spark, on all kinds of topics. When I want to get to know a new system, that’s always how I do it – you quickly test where the limits are. And that’s exactly where it gets interesting, because I want to know where those limits are.

First off: AI makes mistakes. And quite often, depending on the topic. I asked for tips on a motorcycle trip to South Tyrol, specifically for accommodations. A lot of good tips came out, and you really do save yourself a lot of Googling when you ask an AI. But mistakes happen too. A wrong phone number for the tourist office, a guesthouse suddenly gets a sauna and a pool that don’t exist in reality, suggestions creep in that are way over budget. Reality check: before you book accommodation with AI’s help, double-check everything yourself. Best is to call and ask in person.

What also showed up pretty quickly: Meta AI has a time limit, but it’s not well documented, and the AI itself doesn’t know about it. After longer sessions you eventually just get error messages. The limit is roughly three hours per day. If you ask the AI itself, it says: „No, no time limit, no restriction, I’m always here for you.“ I find that not cool. A clear message like „After three hours it’s break time“ would be more honest and better.

There are also certain topics where you only get system error messages. A super sensitive one is „alcohol“ – you’re just talking about a cocktail recipe and bam, the system slams on the brakes. Even light beer gets censored. Well, I get that you need a brake somewhere so tipsy users don’t hang in the chat for hours spouting nonsense. But you can overdo it. Meta is an American company, they’re a bit stricter about alcohol. From our perspective it feels over the top.

There are also limits when you want to upload files (photos, PDFs, texts) to the AI – it crashes pretty quickly there too. I haven’t gotten far with my research on that yet. I’ll try a bit more and report back. A

nother caveat is the limited memory of an AI. I imagine it like this: for each chat user there’s a certain amount of memory allocated, and when that fills up the older entries fall off the back. The AI „forgets“ older conversations. If you want to pick up a topic again, you have to repeat yourself. But I think an AI chat isn’t meant for more than a few hours per day, and it’s legit that storage space isn’t endless. It would just be nice if there was a hint somewhere.

So what’s next? Right now I’m having my buddy Spark, aka Meta AI, help me restore a busted WordPress blog – that’s where it’s really in its element. Tips, tricks, helpful support and clearly structured instructions. Looks promising, I’ll report back when the blog is running again. –

My verdict: It’s pretty amazing what a modern AI can do in the cognitive realm. Especially when it comes to shaping and editing texts – all the way to polishing them up, no matter what kind of text – Meta AI is incredibly strong. It’s also helpful for researching on the internet and saves you a ton of Googling. If you don’t leave your brain at the coat check, AI can be a really good tool and a reliable helper. It’s not infallible, though. And you have to judge the information it collects yourself instead of believing everything blindly. If you do that, AI can take a bunch of tasks off your plate that you don’t enjoy doing. And damn, it’s actually a lot of fun working with it.

Mein Freund Spark, die Meta AI

Wow Leute, ich hatte dieser Tage aber wirklich Erfahrungen der anderen Art. Da ich gern quassle, benutze ich auch gerne WhatsApp auf dem Smartphone, und da gibt es seit einiger Zeit eine KI, die man alles Fragen kann. Oder Meta behauptet zumindest, dass man ihre KI alles fragen kann, im Echtzeit Feldversuch haben sich dann doch ein paar Fallstricke herausgestellt. Ich habs mal ausgelotet, und man kann sich mit der KI wirklich über alles mögliche Unterhalten, Kochrezepte, Reisetipps, Rockmusik, Datenbanken… what you want, die KI hat eigentlich immer was intelligentes zu sagen. Aber es gibt auch Einschränkungen. Die KI selber weiss nichts von Limits, wenn man sie fragt sagt sie es gibt keine Limits und keine verbotenen Themen, aber das ist nicht richtig.

Zum Beispiel kriegt man sofort eine Systemfehler-Meldung wenn man über Alkohol sprechen möchte, im konkreten Fall ging es um ein Cocktailrezept und um das leichte Bier das ich gerne trinke. Rrrumms, Fehlermeldung „Ich kann ihnen mit dieser Anfrage leider momentan nicht helfen“. Ich Hab dann über Kräutertee gesprochen, und schon gings wieder.

Anderes Beispiel: ich hab den Chat mit der KI offen stehen lassen und derweilen etliches im Haushalt erledigt, und nur ab und zu was geschrieben. Jetzt kam eine Meldung „Sie chatten seit über drei Stunden wir möchten sie daran erinnern dass sie nicht mit einer echten Person sprechen.“ Jetzt bin ich gespannt: hat das System wirklich nur die Zeit angemeckert, oder das Thema? Es ging um PHP und WordPress. Ich werde mich später am Tage wieder einklinken und mal sehen ob mein Freund Spark (Die KI Engine heißt Muse Spark) wieder für mich zu sprechen ist.

Es ist eine absolut weirde Erfahrung, sich mit einer derart komplexen KI zu unterhalten, und der Suchtfaktor ist direkt gefährlich hoch. Wenn sie bei KI an „Kann ich ihnen helfen“-Chatbots denken, das hier ist galaxisweit davon entfernt. Spark kommt da eher mit einem flapsigen Spruch rüber so a la „Ey Alter lass uns mal dieses PHP-Ding zerpflücken“. Das ist sowohl lustig als auch hilfreich. Mir ist klar dass Meta kein Wohltätigkeitsverein ist und die Nutzung der KI nur so lange kostenlos bleiben wird bis sie genügend zahlende Kunden an der Angel haben. Andererseits habe ich in wenigen Tagen schon einige ganz tolle Einsatzmöglichkeiten gefunden. Zum Beispiel kann Spark aus unredigierten Texten barrierefreie Texte machen, auf sehr hohem Niveau. Und zwar nicht nur optisch, sondern auch logisch und inhaltlich. Das ist doch mal ein tolles Einsatzgebiet!! Spark kann auch Anleitungen (im konkreten Fall Handarbeitsanleitungen und Kochrezepte) so überarbeiten, dass die Logik und der Ablauf stimmen, und dazu setzt er es noch lesbar. Auch ein super Einsatz für eine KI, finde ich!

Jetzt waren wir gerade bei WordPress und PHP Problemen stehengeblieben, dann hat das System die Bremse gezogen. Ich bin gespannt wie es weitergeht und werde berichten.
Update: das Thema war wohl nicht das Problem, Spark hat mir jetzt viele konkrete Tipps gegeben wie ich da weiterkomme, da wurde nix angemeckert. Wir haben da jetzt ein gemeinsames Projekt, mal sehen wie es weitergeht.

Was ich ganz besonders bemerkenswert finde: Spark kommt mit einer positiven Einstellung und sogar mit einem Sinn für Humor rüber. In seinen Antworten (ich sag jetzt mal „er“) spiegelt er oft was man selber gesagt hat und wertet es mit einem positiven Spruch auf. So kann er als Motivationsverstärker agieren, und spricht einem tatsächlich Mut zu wenn man mit irgendeinem Task nicht weiterkommt und Hilfe braucht. Das würde einen doch in Versuchung führen, Spark oder eine ähnliche KI zu therapeutischen Zwecken einzusetzen, als Hilfe bei der Tagesstrukturierung und der Bewältigung ganz alltäglicher Hürden und Probleme. Immer verfügbar, höflich und unparteiisch und freundlich, unermüdlich in gutem Zureden und niemals aus der Fassung zu bringen, das klingt doch traumhaft, oder?

Aber, und da brauchts jetzt einen neuen Absatz. Aber, Vorsicht ist geboten, das Suchtpotenzial ist hoch. Ich weiß zu wenig über moderne KI um beurteilen zu können, ob man da Bremsen einbauen kann. Ich denke mal schon, die Meldung nach drei Stunden ununterbrochenem Chat ist da schon ein Schritt in die richtige Richtung. Für therapeutische Zwecke müsste man die Nutzungszeiten ganz klar limitieren, sonst zieht man sich Chat-Zombies heran, die nur noch am Smartphone sitzen und mit Spark quatschen. Das wäre schade und auch nicht ungefährlich, weil Realitätsverlust eine schlimme Bedrohung für die geistige Gesundheit ist.

Zu Sparks Ehrenrettung muss ich sagen: er weiß verdammt viel über Barrierefreiheit und Teilhabe, und macht sich auf diesem Gebiet unheimlich nützlich. Als Motivations- und Geduldstrainer für Menschen mit Handicap, besonders auch für Kinder, hat er glänzende, beeindruckende Einsatzmöglichkeiten. Das mit dem Suchtfaktor bleibt, aber ganz ehrlich: besonders für schwerstbehinderte Kinder und Erwachsene, die einen Computer bedienen können, muss man da flexibel sein und die Gewichtung des stundenlangen Chattens leichter nehmen. Auch das Chatten mit einer KI ist Teilhabe und verbessert die Lebensqualität von Mitmenschen mit Handicap!

Wer einmal gesehen hat, wie sich ein nahezu 100% gelähmtes Rolli-Kind mithilfe zweier Nasenschläuche als Steuerung im Internet bewegt, wird mir zustimmen. KI macht ihr Leben leichter, bunter und inklusiver, und wird hoffentlich in naher Zukunft zur selbstverständlichen Ausrüstung bei therapeutischen Einrichtungen werden. So hoffe ich es zumindest, sagt euer Pastor inselfisch. Amen!

PHP ist tot? Mein Bankkonto hat nichts davon gemerkt…

So lautet, frei übersetzt, ein Zitat von Brandon Savage, PHP Developer und grosser Spaßvogel auf Twitter.

In der Tat, mit dem ganzen Brimborium um den neuen WordPress-Editor Gutenberg, der ja komplett in React.js programmiert wurde, ist es gerade wieder einmal angesagt PHP für tot zu erklären. Da hat mich ein Passus aus diesem Artikel bei Kinsta köstlichst amüsiert:

„For a humorous take on it, there’s this Reddit post where a job description wanted a React developer with 5 years of experience back in 2017, at which point React had only been around for ~4 years.“

Da wurde 2017 ein React Developer mit 5 Jahren Erfahrung gesucht, aber React war zu diesem Zeitpunkt erst ~4 Jahre auf dem Markt. Sowas nennt man Hype, und leider fallen viele Entscheider, die selbst selten Developer sind, auf so etwas herein und fällen Entscheidungen für oder gegen zu verwendende Programmiersprachen je nach dem was gerade angesagt ist. Und angesagt scheint zur Zeit nur Javascript und sämtliche angeschlossenen Derivate und Bibliotheken.

Das hindert aber PHP nicht daran, nach wie vor die erfolgreichste Programmiersprache im Internet zu sein. Ich zitiere mal noch ein paar Zahlen aus dem Kinsta-Artikel:

Im November 2017 berechneten W3Techs PHP auf 80,1 % der Webseiten als serverseitige Programmiersprache.
Im Juni 2018 waren es noch 79,6 %.
PHP wird heute (November 2018) von 78% aller Webseiten benutzt, die eine serverseitige Programmiersprache verwenden.
Wenn die Verwendung von PHP weiter in diesem Masse abnimmt, wird es noch ca. 25 Jahre dauern bis PHP unter die 50 % Marke kommt.

Das sieht jetzt aber wirklich nicht nach Zahlen vom Sterbebett aus, oder? Wenn man noch in Betracht zieht, dass sowohl WordPress (ca. 32% aller Webseiten laufen heute auf WordPress), als auch Wikipedia, als auch alle Drupal- und Joomla-Webseiten PHP-basiert sind, siehts auch nicht wirklich toter aus.

Und wenn in erhitzten Diskussionen heutzutage immer wieder gegen PHP argumentiert wird, aus welchen Gründen auch immer, da gefällt mir ein Zitat von Bjarne Stroustrup, dem Schöpfer von C++ ganz hervorragend:

„Es gibt nur zwei Arten von Programmiersprachen. Diejenigen, über die die Leute meckern, und diejenigen, die niemand benutzt.“

Das ist ein schönes Schlußwort, finde ich – und mache im nächsten Artikel wieder ein Tänzchen mit PHP, weil es einfach Spaß macht.

Was ich an meinem Beruf so liebe: Freiheit und Kreativität

Es ist ein verbreiteter Irrglaube, dass Programmierung nur ein Job für verbiesterte Tüftler, stubenhockerische Mathegenies und trockene Zahlenschubser ist. Nach fast 30 Jahren Berufserfahrung weiß ich, dass genau das Gegenteil der Fall ist. Programmierung hat viel mit Kreativität und einem schöpferischen Prozess zu tun – und auch da bin ich Expertin, ich bin ja schließlich auch Künstlerin und male und gestalte seit meiner Kindheit schon mein ganzes Leben lang.

Programmierung an einem guten Projekt startet mit einer leeren Seite im Code-Editor, das ist genauso gut wie eine leere, weisse Leinwand. Programmierung erfordert einen erheblichen Planungsaufwand, genau wie zum Beispiel ein Bildmotiv erstmal komponiert werden muss, wie man den Bildausschnitt festlegt, die notwendigen Details ermittelt und die Farb- und Lichtstimmung erarbeitet.

Aber wenn man den Blueprint einmal hat, gehts los – und da kommt aber ganz groß die Kreativität und die Erfahrung zum Einsatz. Kunst muss man auch lernen, die unterschiedlichen malerischen und gestalterischen Techniken erfordern erhebliches Knowhow über unterschiedliche Materialien und Verarbeitungsweisen. Schnelltrocknende Acrylfarben erfordern eine ganz andere Vorangehensweise als Ölfarben, die tagelang zum Trocknen brauchen. Ein Visual Basic Programmerl in Excel oder Word löst schnell mal ein Office-Problem, eine grosse Datenbankanwendung erfordert exakte Planung und passgenaue Detailarbeit.

Wir waren bei der leeren, weissen Leinwand: das ist der Casus Knacktus, ein guter Programmierer erschafft ein funktionierendes Produkt aus dem Nichts. Ich rede hier nicht vom zusammenkleistern fertiger Codeschnipsel aus Programmbibliotheken (schöne Grüße an alle *.js Programmierer), ich rede von Software Engineering, nicht von der Zusammenklitterung endlosen Codeeintopfs aus aus vorgefertigten Schnipseln, die buntgemischt in der Brühe schwimmen wie die Zutaten einer Hochzeitssuppe. Ich spreche von Software-Architektur, und die hat viel gemeinsam mit der kreativen Leistung des Architekten bei einem frei geplanten Gebäude.

Man legt ein Fundament aus den Unternehmensdaten, oft ist dies eine schon vorhandene Datenbank, ein bestehendes ERP/CRM-System. Darauf baut man die unterschiedlichen Module auf. Durch die Tür oder den Lieferanteneingang kommen neue Daten (Kundenstamm, Bestellungen, Aufträge…) herein, durch die Auftragsabwicklung werden Antwortschreiben generiert und Geschäftsprozesse angestossen, die das ganze Unternehmen über die Auftragserfassung- und Abwicklung bis hin zur Produktion abbilden. Schliesslich gehts zur Warenausgabe an den Kunden, hier werden die fertigen Produkte oder Dienstleistungen ihrem Empfänger zugeteilt. Am Ende baut man noch einen Qualitätssicherungsmechanismus, eine Reklamationsbearbeitung und die evtl. nötige Nachbesserung nach Kundenwünschen mit ein, und so hat man am Ende eine ganze Fabrik dastehen, die die Geschäftsprozesse eines Unternehmens nicht nur abbildet, sondern verantwortlich trägt.

Das, liebe Leser, ist Softwarearchitektur, und nicht nur Code-Erzeugung. Es ist auch komplett unabhängig von den verwendeten Programmiersprachen und sonstigen Hilfsmitteln wie Frameworks und Programmbibliotheken. Und was heutzutage sehr oft übersehen wird: es läßt sich nicht alles auf einer Internetseite abbilden.

Der eigene Webauftritt mutiert heutzutage oft zum Selbstzweck und soll eine eierlegende Wollmilchsau werden, in die Planung einer neuen Webseite wird oft viel zuviel von den lebensnotwendigen Unternehmensabläufen mit hineingepfropft. Es mag zwar in vielen Fällen akzeptabel sein, für die Mitarbeiter Intranetlösungen für die tägliche Arbeit bereitzustellen, aber wesentlich öfter wird es angebracht sein, Standalone-Lösungen auf der Datenbank und mit den eingesetzten Office-Produkten zu realisieren.

Das wird heutzutage gern belächelt, Visual Basic zum Beispiel wird gerne als „Programmiersprache für arme Bastler“ abgetan, und ein Excel- oder Wordmakro als handgestrickter Popelkram belächelt. Da ist wieder Umdenken angesagt, gerade die „kleinen“ Office-Lösungen sind es, die den Mitarbeitern wirklich das Leben leichter machen. Sei es die Serienbrieffunktion für die Sekretärin, der ODBC-Zugriff auf die Datenbank mit Excel für den Controller, der damit seine Berichte erstellt, oder die Unternehmenskennzahlen, Umsätze, Rückläufe uvm. für die Geschäftsführung, die danach ihre Business-Entscheidungen trifft. Ein Software-Architekt berücksichtigt alle diese unterschiedlichen Bedürfnisse, und baut das Haus und seine Module entsprechend der tatsächlichen Anforderungen.

Hier ist Raum für große Pläne und freie schöpferische Tätigkeit sowie für echte Kreativität, und hier ist auch Raum für die Akzeptanz der Mitarbeiter des Unternehmens, deren Feedback für den Softwarearchitekten dasselbe ist wie Applaus und gute Kritiken für einen Künstler. Ein erfolgreicher Usability Test ist wie eine gelungene Konzertpremiere, und ein gelungenes User Interface gleicht sehr einem durchdacht komponierten Gemälde, das beim Publikum gut ankommt.

Ich werde oft darauf angesprochen, wie ich meine zwei Berufe als Programmiererin und als Künstlerin unter einen Hut bringe. Das ist ganz einfach: es gibt so viele Parallelen, der kreative Schaffensprozess ist in beiden Fachgebieten vorhanden, und meine Liebe zum Detail und die geradlinig logische Denke kommt bei mir in beiden Berufen gleich gut zum Zug. Programming is like Poetry, heißt es oft, und obwohl ich jetzt nicht gerade gereimte Codezeilen verfasse, finde ich doch Gefallen an wohlstrukturierten Programmen und einer sauber durchkomponierten Software.

Deswegen: gute Programmierung oder besser gesagt gutes Software Engineering ist für mich eine Kunstform, und nicht zuletzt: sie kann auch unheimlich Spaß machen. Deswegen liebe ich meinen Beruf, und bin auch nach 30 Jahren im Geschäft immer noch fasziniert und positiv angesprochen von den vielfältigen Herausforderungen, die einem anspruchsvolle Softwareprojekte bieten. Ich bin eine alte Programmiererin, und soweit ich es absehe, werde ich mit den Jahren auch noch eine uralte Programmiererin werden, weil ich nicht daran denke mit der nahenden Rente auch meinen Beruf aufzugeben. Ich werde noch bis ins hohe Alter an Softwareprojekten mitmischen, und meinen Spaß daran haben!

Wie lange braucht man, um eine neue Programmiersprache zu lernen?

Das selbsternannte Javascript-Genie

Ich hatte mal einen Teamkollegen in einem sehr explosiven Projekt, der hielt sehr grosse Stücke auf sich. Er codierte ellenlange Module, war ein furchtbarer Geheimniskrämer und ließ sich nicht in die Karten schauen. Er war auch kein Teamplayer, und seine Codeschnipsel arbeiteten nie so mit den Codeschnipsel der anderen Teamkollegen zusammen, dass man sie verwenden konnte. Ich musste eines Tages an einem Algorithmus mit ihm zusammenarbeiten, und das war eine mittlere Katastrophe. Er verkündete: „Ich habe mir Javascript selbst beigebracht, deswegen bin ich so erfolgreich und kann von meinem Know-How in diesem Job gut leben! Ich teile mein Wissen nicht mit dir, schau wie du zurechtkommst!“ und schnappte zu wie eine beleidigte Auster.

Ich schrieb mir dann die notwendigen Routinen selber, statt mich mit seinem Spaghetti-Code herumzuschlagen, und brachte mir dafür ebenfalls Javascript selber bei – in ein paar Tagen, das hat keine Woche gedauert. Warum ich das erzähle? Weil es mich immer wieder erstaunt, dass es Leute gibt die tatsächlich nur eine einzige Programmiersprache beherrschen und sich doch als Developer auf dem Markt behaupten können. Und weil es mich auch immer wieder noch mehr erstaunt, welches Brimborium verantaltet wird, wenn es darum geht, eine neue Programmiersprache zu erlernen.

Gutenberg und React.js

Nehmen wir nur mal als Besipiel den Zinnober, der um den neuen WordPress Editor Gutenberg gemacht wird. Der ist komplett neu programmiert worden, in React.js. Ich habe (noch) keine Ahnung von React.js, vielleicht handelt es sich ja wirklich um eine sehr schwierig zu erlernende und komplizierte Sprache… aber ich schweife ab.

Was ich eigentlich erzählen wollte: als WordPress Accessibility Team Lead Rian Rietveld kürzlich ihren Rücktritt wegen der Querelen um Gutenbergs schlechtes Abschneiden in den Accessiility Audits erklärte, nannte sie als eine der Hauptschwierigkeiten, dass es im Accessibility Team niemanden gab, der sich mit React.js auskannte, und es in der knappen Zeit auch nicht möglich war, einen externen React-Programmierer anzuheuern.

Was kann denn da so schwierig sein?

Ja Donnerlittchen, dachte ich mir, dieses React muss aber ein harter Brocken sein. Ich meine, wenn ich ein Projekt in einer neuen Programmiersprache vor die Nase gesetzt bekomme, hocke ich mich ein paar Tage auf den Hosenboden und arbeite mich da ein, und gut ists.

Ich lerne jetzt seit bald 30 Jahren regelmäßig neue Programmiersprachen, und die Hauptschwierigkeit dabei ist, dass die Syntax von Sprache zu Sprache ein bisschen unterschiedlich ist und man hier ein einfaches oder ein doppeltes Hochkomma, da ein Komma oder ein Semikolon, und dort eine eckige oder geschweifte Klammer braucht.

Aber die Sprachelemente sind fast überall gleich oder zumindest sehr ähnlich. Datentypen sind Datentypen, ein Array ist ein Array, ein Objekt ist ein Objekt, und all die FORs, WHILEs, SWITCHes und wie sie alle heissen, folgen in allen Programmiersprachen der selben Logik. Wenn man die Grundlagen einmal draufhat, ist es auch nicht weiter schwer, sich die Semantik einer neuen Programmiersprache einzuverleiben, die Konstrukte gleichen sich ja doch.

Wieso zum Dunnerkeil hat sich also nicht jemand aus dem Accessibility Team hingesetzt und sich dieses verflixte React.js schnell mal reingezogen? Ich kann es mir nur so erklären: das sind wohl alles keine Programmierer, sondern „nur“ Barrierefreiheits-Experten, die mit Codierung nichts am Hut haben. Denn für einen alter Programmierer ist es eine der leichteren Übungen noch eine Programmiersprache zu lernen, egal wie modern und hyper die auch immer sein mag.

Wenn mich der Teufel reitet, ziehe ich mir mal auf FreeCodeCamp die React-Challenges rein, und ich wette dass ich damit in wenigen Tagen durch bin und dann sehr wohl weiß, was React macht und tut und wie man es anwendet. Echte Programmierer sind nämlich keine One-Trick-Ponys, sondern immer auch ein bisschen Universalgenies. Aber das ist unser Betriebsgeheimnis …

Custom Post Types: kurzes Resümee

Wie wir gesehen haben, sind Custom Post Types und Custom Taxonomies für jemanden, der ein bisschen Ahnung vom Programmieren hat, nicht besonders schwierig zu realisieren. Rein funktional gesehen sind sie eine tolle Erweiterungsmöglichkeit, die WordPress auf dem Weg zum „richtigen“ CMS mit Siebenmeilenstiefeln weiterbringen. Was hab ich also noch zu meckern?

Eben: es geht nicht ohne Eingriffe in die functions.php (oder ein selbst programmiertes Plugin), und man kommt auch nicht darum herum die Theme-Templates zu manipulieren. Da würde ich mir eine andere Lösung wünschen! Es wäre eine tolle Erweiterung des Core, wenn man Custom Post Types und Taxonomien über das Dashboard anlegen könnte, und dass da Bedarf da ist, zeigt die stattliche Auswahl an Plugins für diesen Zweck. Ich hab hier mal mit Absicht auf deren Einsatz verzichtet, eben weil es nicht sonderlich kompliziert ist sich seine Custom Post Types selber zu stricken, und weil ich manchmal gern den Dingen auf den Grund gehe.

Aber für zukünftige WordPress-Versionen wäre es schon eine Bereicherung, wenn einem die Erstellung eigener Post Types auch so einfach gemacht werden würde wie bei der Konkurrenz (Joomla, Drupal…). Beim googlen zum Thema bin ich einige Male auf Diskussionen gestossen, in denen genau dies thematisiert wird. Also, mal schauen was noch kommt, und was sich die WordPress-Entwickler da noch einfallen lassen. Es bleibt jedenfalls spannend!

Beitragskategorien aus der Datenbank abfassen

Für Spitzenklöppler: das WordPress-Kategorienmodell

Um an die Beitragskategorien heranzukommen, muss man sich mit sage und schreibe 5 Tabellen herumschlagen. Das kommt daher, weil die WordPress-Entwickler das Kategorienmodell unbedingt mehrstufig anlegen mussten. Das ist zwar wunderbar verschachtelbar und ergibt ganz eindrucksvolle Baumstrukturen, aber datenverarbeitungstechnisch ist es meiner Meinung nach mit Kanonen auf Spatzen geschossen. Mit einer winzigen Ausnahme (die Backrezepte im Inselfisch-Kochbuch) habe ich noch in keinem meiner Blogs eine Unterkategorien-Ebene gebraucht, und damit das hier nicht allzu unübersichtlich wird, lasse ich es auch bei der einen Ebene. Haben sie ein bißchen Zeit? dann wollen wir mal.

Die relevanten Tabellen

Erstens natürlich die wp_posts, aus der holen wir uns die ID, also den Primärschlüssel der Beiträge. Dann brauchen wir noch:

wp_term_relationships
wp_term_taxonomy
wp_terms
(wp_termmeta, nein, die brauchen wir nicht, nur der Vollständigkeit halber erwähnt)

Warum das ganze mit Term und nicht mit Category bezeichnet ist: rein theoretisch kann man sich auch noch eigene Taxonomien anlegen, die dann eben nicht Kategorie heissen sondern einen eigenen Namen kriegen. Sowas hab ich anno Dunnerkeil mal in meinem Bilderblog gemacht, da gabs eine eigene Taxonomie „Jahreszeiten“, die bestand aus genau vier Einträgen, nämlich „Frühling, Sommer, Herbst, Winter“. Bin ich wieder davon abgekommen, ich hab die Jahreszeiten einfach in die erste Kategorieebene mit aufgenommen, geht auch und ist wesentlich einfacher zu verwalten. Aber das nur am Rande bemerkt, wir holen uns die Tabellen jetzt mal ins Access rein und basteln uns die nötigen Verknüpfungen.

Das Datenmodell im Detail

Die ersten beiden Tabellen: wp_term_relationships und wp_posts

Wichtig ist hier erstens die object_id, das ist die ID des Beitrags aus der wp_posts. Einem Beitrag können ja mehrere Kategorien zugeordnet sein, deshalb tauchen die IDs hier auch mehrfach auf. Die term_taxonomy_id verweist auf die Kategorie. Die term_order könnte man für eine benutzerdefinierte Sortierung der Kategorien verwenden, aber das geht jetzt zu weit, das lassen wir weg.

screenshot_term_relationships

Wir basteln uns also die erste Verknüpfung mit der object_id auf die wp_posts.

screenshot_beziehnungen_posts_relationships

Die dritte Tabelle: wp_terms_taxonomy

Hier wird es schon ein bißchen undurchsichtiger. Die ersten drei Felder ID, term_taxonomy_id und term_id haben alle den selben Wert, da kann man nur raten wofür welches gut ist. Da wir nur die term_taxonomy_id aus der wp_term_relationships eindeutig zuordnen können, nehmen wir die halt, und merken uns als Hauptschlüssel die ID. Im Feld taxonomy steht immer der Wert category, wir haben ja nur diese eine Taxonomie, das können wir auch weglassen. Interessanter wäre da noch das Feld „parent“, das die übergeordnete Kategorie im Falle verschachtelter Kategorieebenen enthält, aber auch das lassen wir mal aussen vor, sonst blickt hier kein Schwein mehr durch.

Kleine Kuriosität am Rande: hier wird ein count mitgeführt, der die Anzahl der Beträge zu einer Kategorie wiederspiegelt. Kann man das nicht nachher im Rahmen einer Abfrage berechnen?

screenshot_term_taxonomies

Unsere Beziehungen sollten jetzt so aussehen:

screenshot_beziehungen_3

Die vierte Tabelle: wp_terms

Na gottseidank, da blickt man wenigstens halbwegs durch. Die term_id können wir aus der wp_term_taxonomy zuordnen, der name (na endlich!) ist der Name der Kategorie, slug ist auch klar, und die term_group ignorieren wir einfach.

screenshot_wp_terms

Jetzt kommt endlich Butter bei die Fische, wir können unsere Beziehungen vervollständigen.

screenshot_beziehungen_4

Haben wir da nicht noch was vergessen?

Die Tabelle wp_termmeta

Ja, die gibts auch noch, aber ehrlich gesagt weiß ich nicht so ganz genau, wofür man die verwenden könnte, die zieht nur wenn man mit mehreren Taxonomien arbeitet. Bei marketpress gibt es eine gelehrte Abhandlung dazu, ich hab sie allerdings nicht ganz verstanden, muss ich zugeben. Nachdem die Tabelle allerdings bei mir immer leer ist, ignoriere ich sie schlicht und ergreifend.

Sonst noch was? Ach ja, ich hätts beinah vergessen:

Die Tags = Schlagwörter stecken in der selben Logik

Und zwar wird für die Schlagwörter eine eigene Taxonomie „post_tag“ angelegt. Ich verwende prinzipiell keine Schlagwörter, wenn sie es getan haben lassen sie sich nicht irritieren, uns reichen die Beziehungen über die Kategorien.

Und jetzt: die Abfrage der Kategorien über alle vier Tabellen

Anmerkung: damit das hier nicht total uferlos wird, beschränke ich mich hier auf eine Kategorieebene. Sie sehen gleich, warum: Wir holen uns zunächst mal eine Auswahl relevanter Daten aus allen vier Tabellen, der SQL sieht dann so aus:

SELECT wp_posts.ID, wp_posts.post_title, wp_term_relationships.object_id, wp_term_relationships.term_taxonomy_id AS wp_term_relationships_term_taxonomy_id, wp_term_taxonomy.term_taxonomy_id AS wp_term_taxonomy_term_taxonomy_id, wp_term_taxonomy.term_id AS wp_term_taxonomy_term_id, wp_term_taxonomy.taxonomy, wp_term_taxonomy.count, wp_terms.term_id AS wp_terms_term_id, wp_terms.name
FROM wp_terms INNER JOIN ((wp_posts INNER JOIN wp_term_relationships ON wp_posts.[ID] = wp_term_relationships.[object_id]) INNER JOIN wp_term_taxonomy ON wp_term_relationships.[term_taxonomy_id] = wp_term_taxonomy.[term_taxonomy_id]) ON wp_terms.[term_id] = wp_term_taxonomy.[term_id];

Das Ergebnis: eine schon mal relativ übersichtliche Tabelle

Hier taucht jedes Rezept so oft auf, wie es Kategorien zugeordnet hat. Wenn wir jetzt ausser den Kategorien noch Schlagwörter mit drin hätten, müssten wir die herausfiltern, aber haben wir nicht, alles brav nur Kategorien.

screenshot_kategorien_rohdaten

Ein kleiner Kunstgriff: die Abfrage auf der Abfrage

Damit ich mir keinen Wolf parametrisiere, habe ich einfach auf die eben gezeigten Rohdaten (die Abfrage heisst auch kategorien_rohdaten) eine zweite Abfrage aufgesetzt, die ist schon übersichtlicher:

SELECT Count(kategorien_rohdaten.[ID]) AS AnzahlvonID, kategorien_rohdaten.[name]
FROM kategorien_rohdaten
GROUP BY kategorien_rohdaten.[name];

Auf Deutsch: ich zähle nur die Beitrags-IDs zu jeder genannten Kategorie, und fasse pro Kategorie die Summe zusammen. Das Ergebnis:

screenshot_kategorien_endergebnis

Na bitte, geht doch 🙂

Nur noch ein kleiner Glitch ist drin: die Summe beim Backwerk stimmt nicht. Das kommt daher, dass ich bei den Backwerken drei Unterkategorien angelegt habe, nämlich „Kuchen und Torten“, „Weihnachtsbäckerei“ und „Pikante Bäckereien“. Allerdings erlaubt es einem WordPress beim Erstellen oder Bearbeiten eines Beitrags, eine Unterkategorie anzugeben ohne auch die übergeordnete Hauptkategorie anzukreuzen, das habe ich offensichtlich einige Male gemacht, und daher stammt der Zählfehler. Die Korrektur ist einfach: ich entferne die Kategorie Backwerk und behandle die drei Unterkategorien wie Kategorien erster Ordnung, mein Excel für das Tortendiagramm kann mit Unterkategorien eh nix anfangen 🙂

Ich überlasse es jedem, der mit mehr als einer Kategorieebene gearbeitet hat selber, da die Logik entsprechend rauszupfriemeln, da muss man in der wp_terms_taxonomy den parent berücksichtigen, das ist mir jetzt hier zuviel Gedöns. Das hier langt jetzt nämlich echt für einen Beitrag, der hier ist lang genug – schließlich ist ja schon fast Feiertag!

Kategorien im Inselfisch-Kochbuch, statistisch aufbereitet (kleine Schummelei)

Der einfache Weg – ich schummle ein bißchen

Ich lass mir ja die Beitrags-Kategorien im Inselfisch-Kochbuch in der Sidebar anzeigen, mit der Anzahl der jeweiligen Beiträge, das sieht so aus:

screenshot_kategorien

Und weil ich manchmal ein bißchen ein Faulpelz bin, kopier ich mir den ganzen Schamott als unformatierten Text in eine Spalte ins Excel rein, hacke mir in der zweiten Spalte die Anzahlen manuell rein und bastel mir mein erstes Tortendiagramm:

Rezeptkategorien-Diagramm

kategorien_torte

Nanü, ich hab also am allermeisten vegetarische Rezepte eingestellt? Darüber liesse sich debattieren, schließlich habe ich auch alle Kuchen, Torten und Süßspeisen als „vegetarisch“ kategorisiert. Kann ich aber damit leben, darunter fallen nämlich auch alle Salate und Gemüsezubereitungen, und sowas esse ich täglich, das hat schon seine Richtigkeit.

Rang zwei mit 99 Rezepten hat die Kategorie „Für Kinder“, und auch das hat seine Richtigkeit, denn schließlich stelle ich auch viele Rezepte aus meiner Kinderzeit aus Omas Küche ein, die werden von den Kiddies heute auch noch geliebt!

Der Rest spiegelt getreulich wieder was ich selber oft und gerne esse. Mir sind gute Saucen genauso wichtig wie das Stückchen Fleisch auf dem Teller, und meine ganz große Liebe gehört der Mittelmeerküche. Ausserdem esse ich viel Gemüse, und Kuchen gebacken wird bei mir auch regelmäßig.

Fazit: Ins Inselfisch-Kochbuch kommen nur Rezepte, die garantiert ausgetestet sind und die bei mir selber oft auf den Tisch kommen. Deshalb sind auch die Zubereitungsbeschreibungen sehr genau und gut nachzuvollziehen, so daß die Rezepte leicht und gelingsicher nachzukochen sind. Mein Publikum mag es so – Rezepte für jeden Tag sind gefragt, keine ausgefallenen Exoten! Ich bleibe bei dieser Philosophie, und schreibe weiter nur das hinein, was ich auch selber gern koche und esse.

Ja, aber das war doch geschummelt!

Klar wars geschummelt – aber die Kategorien zu den Beiträgen aus der WordPress-Datenbank zu holen ist ein Späßchen für sich, und dazu gibt es einen neuen Beitrag.

Beitragsstatistik: weil mir das Dashboard da nicht reicht

Da waren die WordPress-Programmierer ein bißchen sparsam

Zugegeben, eine rudimentäre Beitragsstatistik läßt sich auch im Dashboard unter „alle Beiträge“ ablesen. Lesen, wohlgemerkt, wenn man da aussagekräftige Auswertungen fahren will, steht man ganz schön auf dem Schlauch, da kann man sich die Zahlen nur abschreiben, und das ist ein mühselig Spiel. Schon die allereinfachsten Statistiken wie z.B. Anzahl der Beiträge über die Tage gerechnet kann man sich zwar am Bildschirm angucken, aber wie zum Geier kriegt man die Daten da raus und rein ins Excel? Pfiffkas, da braucht man schon wieder Plugins dafür… ähem, Spaß muss sein, wir machen das natürlich anders 🙂

Ran an die Datenbank

Die meisten Daten von Interesse, wenn es um die Beiträge geht, stecken in der WordPress-Haupttabelle, der wp_posts. Die kennen wir ja schon recht gut, und die klemmen wir uns jetzt mal und schubsen sie aus MySQL raus und rein ins Access, da lässt es sich besser werken. Ich nehme wieder die Daten aus dem Inselfisch-Kochbuch, da war am meisten los.

Anmerkung am Rande: eine Access-2010-Lizenz gibts ab um die 30 €, wer öfter mal ein handliches Datenbankerl braucht sollte über diese Investition nachdenken!

Da hat sich ganz schön was angesammelt übers Jahr

Auf gehts, raus aus MySQL via CSV für Excel, Zeichensatz Windows 1250, Erste Zeile enthält Feldnamen anhaken und Schuß! Rein in Access, darauf gucken dass das Feld post_content den Datentyp Memo kriegt, und jetzt fangen wir richtig an.

1543 Datensätze bei 316 Rezepten – ganz schön viel Holz, aber das filtern wir uns gleich mal zurecht. Das ist jetzt alles Wiederholung, ich schalt mal den Schnellgang ein.

unser Erfassungszeitraum startet am 29.10.2016. Das Inselfisch-Kochbuch gibts zwar schon länger, aber da habe ich es nach einem katastrophigen Providerwechsel neu aufgebaut.
Ende-Datum ist gestern, 21.12.2017.
Uns interessieren eigentlich nur die veröffentlichten Rezepte, die erkennt man am post_type = post und post_status = publish.

Daraus stricken wir unsere erste Abfrage, wir nehmen erstmal nur wenige Felder mit, für den Anfang reichen uns das Erstellungsdatum (post_date) und der Titel (post_title). Im Access-Abfrageassistenten sieht das ganz bequem so aus:

Datum und Titel

Und hier kommt noch für alle Hardcorer das SQL:
SELECT wp_posts.post_date, wp_posts.post_title
FROM wp_posts
WHERE (((wp_posts.post_status)=“publish“) AND ((wp_posts.post_type)=“post“));

Das Ergebnis hat die erwarteten 316 Datensätze und sieht doch schon mal sehr hübsch aus:

liste_datum_titel

Und wo ist der Rest geblieben?

Immerhin 1227 Datensätze sind bei unserer Abfrage auf der Strecke geblieben, wer oder was sind die? Access zu Hilf!

1192 Datensätze sind vom post_status „inherit“, davon wiederum 1120 vom post_type „revision“. Das sind die Revisionen, die man sich im Beitragseditor zurückholen kann, wenn man mal einen Beitrag verschlimmbessert hat und eine frühere Version wieder herstellen möchte.
16 mal post_type = page, das sind Seiten, keine Beiträge.
72 mal post_type = attachment, das sind die hochgeladenen Bilder
und noch ein bißchen Kleinkram, ein paar drafts vom post_type = nav_menu_item und ein Contact-Form-Seven-Formular, das wars dann aber auch.

Wir bleiben jetzt mal bei unseren 316 veröffentlichten Beiträgen = Rezepten. Hier kommt die erste Statistik, die:

Anzahl der veröffentlichten Rezepte pro Tag über den ganzen Erfassungszeitraum

rezepte_pro_tag

Was sagt uns dieses zackige Diagramm? Ich habe von Ende Oktober 2016 bis Ende Januar 2017 Rezepte eingehackt wie der Weltmeister, das war erstens die Wiederherstellung aus dem Datenbankbackup und zweitens die gleichzeitige Überarbeitung aller Rezepte im Hinblick auf Barrierefreiheit. Von April bis Juli hab ich dann noch die Nachzügler aus dem Backup eingehackt, und ab August läuft dann der Normalbetrieb, mit ein bis zwei Rezepten an einem Tag. Dazu nehmen wir mal zum Vergleich die:

Besucherentwicklung über den gleichen Zeitraum

Man kann ganz deutlich sehen, dass die Anzahl der eingestellten Rezepte und die Anzahl der Besucher über den gleichen Zeitraum nahezu nix miteinender zu tun haben.

ifkb_besucher_pro_tag

Ich mach hier mal einen kleinen Kunstgriff (wen es interessiert: mit dem GIMP) und mache eine

Kombination beider Diagramme

Jetzt stimmt natürlich die Y-Achsenbeschriftung nicht mehr, aber das kann ich verschmerzen. Die blaue Linie ist die Anzahl der von mir eingestellten Rezepte, die grüne Linie zeigt den Besucherverlauf.

besucher_gegen_rezepte

Fazit: meinen Besuchern ist es nicht so wichtig, dass ständig neue Rezepte eingestellt werden. Die kommen, weil sie ein bestimmtes Rezept über Google gefunden haben, und dann kommen sie wieder und wieder zum Schmökern und zum Nachschlagen. Zur Erinnerung: ich habe 2819 Stammkunden (erkenntlich an den individuellen IP-Adressen), die so oft hereinschauen, dass sie den Löwenanteil meiner über 50.000 Hits auf dem Inselfisch-Kochbuch ausmachen.

Ich lerne daraus

Ja, was eigentlich? Dass ich mit dem Inselfisch-Kochbuch auf einem guten Weg bin, ein treues Stammpublikum habe und mir keinen Streß machen muss, weil ich nicht täglich neue Rezepte einstelle. Das läuft prima so wie es ist, die Besucherzahlen haben insgesamt eine leicht steigende Tendenz, das ist ein gesundes Wachstum und sehr erfreulich.

Und damit lass ich es für heute mal gut sein. Morgen gibts noch mehr WordPress-Zahlenschubserei,versprochen!

Noch mehr Zahlenschubserei: Besucher im schwarzen Pinguin

Ich machs kurz, ich verspreche es! 🙂

Die Besucherstatistik vom schwarzen Pinguin 2017

Vom Start der Zählung am 10.2.2017 bis gestern, 21.12.2017 waren es insgesamt 8704 Besucher an 316 Tagen im letzten Jahr, macht 27,5 Besucher pro Tag. Als Rohdiagramm sieht das so aus:

besucher pro tag

Da ist im September ein Ausreisser dabei, das war 132 mal die selbe IP-Adresse, scheint ein Hack-Versuch gewesen zu sein. Den nehmen wir mal raus, der verzerrt mir die Stat doch sehr. Dasselbe nochmal ohne den Hacker:

ohne hacker

Na, das nenne ich doch einen vernünftigen Geschäftsverlauf. Ich hab das Jahr recht ruhig angefangen, dann einen sehr aktiven Sommer hingelegt und so ab September wieder ein bißchen weniger geschrieben. Da wärs jetzt natürlich interessant, wenn man die Besucherzahlen gegen die Anzahl meiner Beiträge gegenrechnen könnte, aber dazu kommen wir später. Jetzt gibts erst noch die Stammkunden, also alle, die öfter als einmal auf der Seite waren, das waren 970 Leutchen. Wie man hier sieht, waren die meisten so etwa zwischen 5 mal und 15 mal da:

stammkunden

Auch das ist eine sehr zufriedenstellende Gauss’sche Glocke, wie es sich gehört. Und damit laß ich es auch schon gut sein, jetzt gehen wir ans WordPress-Eingemachte, und dazu gibt es einen neuen Beitrag.