Archiv der Kategorie: Allgemein

Eine kleine Essensumfrage – Ergebnisse

Ende letzten Jahres haben wir eine kleine (nicht-repräsentative) Essensumfrage gestartet: Welche Essen sind besonders beliebt, gibt es verschiedene “Esstypen” und korrelieren Essvorlieben mit Reisezielen?

Die Ergebnisse

Nun präsentieren wir die Ergebnisse. Es haben 60 Personen teilgenommen, von denen die meisten 20 – 40 Jahre alt waren. Ein erstaunlich hoher Anteil von über 15 % gab an, sich vegan zu ernähren. Das Verhältnis zwischen weiblichen und männlichen Teilnehmenden war ausgeglichen. Im Mittel wurden etwa 60% der abgefragten Lebensmittels gerne gegessen.

Körnerbrötchen, Orangen und Schokolade gehörten zu den beliebtesten Essensgegenständen. Alge hatten immerhin 17 % noch nie gegessen. Bei einigen der abgefragten Essensgegenständen hat sich eine Abneigung im Laufe des Lebens in eine Zuneigung gewandelt. Hier wurden auffällig viele Gemüse genannt, allen voran Oliven. Insgesamt mochten vegan lebende Menschen mehr der abgefragen Essen als die restlichen Teilnehmenden.

Schließlich gab es gewisse Zusammenhänge zwischen den Essensvorlieben und demographischen Merkmalen, wie besuchten Kontinenten, Lieblingsfarben und genutzten Betriebssystemen. Beispielsweise zeigte sich, dass Inwger besonders bei den Teilnehmenden beliebt war, die auch Nordamerika besucht hatten. Andererseits waren z.B. weiße Brötchen besonders bei Südamerika-Reisenden unbeliebt. Weitere Ergebnisse und Erklärungen gibt es über die Links.

Bis bald und liebe Grüße!

Eine kleine Essensumfrage

In diesem Beitrag geht es um ein kleines Seitenprojekt: Eine (nicht-repräsentative) Essensumfrage um einen Eindruck zu bekommen, welches Essen wie (un-)beliebt ist, ob Essvorlieben mit Reisezielen korrelieren, ob es verschiedene “Esstypen” gibt und vieles mehr.

Die Idee

Während des Mittags reden wir oft über Essen. Über verschiedene Geschmäcker, wie (un-)beliebt bestimmte Essen sind und ob es vielleicht verschiedene Esstypen gibt (Leute, die Lakritze mögen, essen ungern XY?). Um etwas Licht in diese Fragen zu bringen, weil wir keine zugänglichen Studien finden konnten, und mit allen Werkzeugen der Web-Entwicklung und Statistik im Handgepäck, entschlossen wir uns für ein Seitenprojekt.

Nun präsentieren wir eine kleine Essensumfrage! Da wir keine repräsentative Stichprobe auswählen, lassen sich die Ergebnisse nicht verallgemeinern. Die Ergebnisse sagen nur etwas über die teilnehmenden Personen aus, nicht über Deutschland, sicher nicht über die ganze Welt. Wir hoffen, dass die Ergebnisse uns und dir trotzdem Freude bereiten und einige interessante Zusammenhänge liefern.

Weitere Infos

Nachdem du dich durch drei mittelkurze Seiten mit Fragen geklickt hast, gibt es außerdem einige vorläufige Ergebnisse zu sehen und wie die Anderen im Vergleich zu dir geantwortet haben. Außerdem gilt selbstverständlich:

  • Alle Ergebnisse sind vollständig anonym und werden nicht kommerziell genutzt.
  • Über den Verlauf unserer kleinen Umfrage werden wir hier in diesem Blog-Beitrag informieren.
  • Wenn du die Umfrage weitergeben möchtest, bist du herzlich dazu eingeladen.

Wir freuen uns über Kommentare und Fragen. Viel Spaß!

Der R style guide von daqana ist online

Er ist eine Weiterentwicklung des tidyverse style guides (http://style.tidyverse.org/).

Was ist eigentlich ein style guide und wozu ist er gut?

Ein style guide – zu deutsch: Gestaltungsrichtlinie – gibt Programmierern Regeln vor, wie sie ihren Code gestalten sollen. Um zu funktionieren, muß der Code einer bestimmten Grammatik und Interpunktion folgen. Hierbei gibt es, wie auch in der normalen Sprache, gewisse Freiheiten.

In einem style guide werden Empfehlungen ausgesprochen, die diese Freiheiten mit dem Ziel der Vereinheitlichung einschränken. Teilweise sind die Empfehlungen für eine bestimmte Variante relativ willkürlich. Mitunter ist eine Variante aber in Bezug auf verschiedene Qualitätskriterien auch besser geeignet als eine andere. Diese Qualitätskriterien können etwa die Lesbarkeit und Verständlichkeit, aber auch die Leistungsfähigkeit (Schnelligkeit, Skalierbarkeit) des Codes betreffen.

Die Vorteile, die sich ergeben, wenn Programmierer einem gemeinsamen style guide folgen, sind also zum einen die Einhaltung von Qualitätsstandards, zum anderen ein einfaches Sich-zurecht-Finden im Code, auch wenn er von anderen oder gemeinsam geschrieben wird, und damit nicht zuletzt eine bessere Wartbarkeit und Erweiterbarkeit des Codes.

Warum wurde der tidyverse style guide als Vorlage benutzt und warum wurde er nicht 1:1 übernommen?

Das tidyverse umfaßt eine Menge Pakete, von denen viele es erleichtern, die Qualität der eigenen Analysen zu erhöhen, und die schnell sehr populär wurden. Grundlage für den tidyverse style guide ist neben dem „Google R style guide“ (https://google.github.io/styleguide/Rguide.xml) offensichtlich auch das ausgezeichnete Buch von Hadley Wickham zur Paketentwicklung („R packages“ http://r-pkgs.had.co.nz/).

Der tidyverse style guide umfaßt neben einem klassischen Kapitel zur Syntax auch Hinweise zur empfohlenen Praxis bei der Paketentwicklung. Diese breite Auffassung, wie auch die Expertise und die weite Verbreitung waren für uns die Gründe, den tidyverse style guide als Richtlinie für unsere tägliche Arbeit zu prüfen.

Tatsächlich stimmt der daqana style guide zu sehr großen Teilen mit dem tidyverse style guide überein. An einzelnen Stellen haben wir Erklärungen für bestimmte Entscheidungen hinzugefügt, insbesondere wo wir doch Änderungen vorgenommen haben. Dem Kapitel zur Pipe wurde ein Absatz vorangestellt, da ihre Nutzung eher kritisch gesehen wird. Ein kurzes Kapitel zu Unit Tests wurde eingefügt.

Der sichtbarste Unterschied ist, daß gute und schlechte Beispiele farblich hervorgehoben wurden, was unserer Auffassung nach die Nutzerfreundlichkeit erhöht. Wir haben uns außerdem bemüht, direkt an den entsprechenden Stellen Hinweise auf passende lintr-Funktionen (https://github.com/jimhester/lintr) anzugeben und stellen diese in der Datei daqana_linters.R zur Verfügung, so daß eine direkte Einbindung dieser linter im entsprechenden RStudio Add-In möglich ist.

Wir sehen den style guide nicht als abgeschlossenes Werk an, werden prüfen, wie er sich in unserem Alltag bewährt und planen für die Zukunft unter anderem eine Zusammenstellung von passenden styler-Funktionen  (https://github.com/r-lib/styler) analog zu den linters.

Hier ist also die erste Version des daqana R style guides. Viel Freude damit! https://www.daqana.org/dqstyle-r/

Shiny-Apps mit testthat (unit-) testen

In diesem Blog-Beitrag wird erklärt, wie man eine Shiny-App mithilfe der Pakete shinytest und testthat testen kann. Grundlegende Vorkenntnisse über Shiny-Apps und das Prinzip von Unit-Tests mit dem Paket testthat sind nützlich, werden hier aber nicht vorausgesetzt.

Beispiel einer Shiny-App

Für den hier vorgestellten Test sind die Pakete shiny (aktuell: 1.1.0), testthat (1.3.0) und shinytest (2.0.0) erforderlich. Falls nötig können sie bequem mit install.packages() installiert werden.

Unten ist ein minimales Beispiel einer Shiny-App (app.R), die getestet werden soll. Die App hat nur einen einzigen numerischen Input und einen Text-Output. Die eingegebene Zahl n wird quadriert und das Ergebnis wird als Text angezeigt.

Und so sieht die App aus:

Was ist shinytest?

Das Paket shinytest ermöglicht das automatische Testen einer Shiny-App. Dabei wird sowohl das “Aussehen” der App, sowie ihr “interner” Zustand zu einem bestimmten Zeitpunkt im Programmablauf untersucht. Mithilfe eines interaktiven User-Interfaces lassen sich Snapshots (genauer gesagt Referenz-Snapshots) sowie eine Test-Datei erstellen. Die Test-Datei beinhaltet den Code, der für spätere Wiederherstellung der Snapshots erforderlich ist. Bei jedem weiteren Test werden neue Snapshots erstellt und mit den Referenz-Snapshots verglichen, um unerwartetes Verhalten der Shiny-App automatisch zu detektieren. Mehr zu dem normalen Workflow mit shinytest ist hier zu finden. In diesem Blog-Beitrag wird allerdings ein anderer Umgang mit dem Testen beschrieben; Nämlich das gemeinsame Testen mittels shinytest und testtthat [*].

[*] Nicht hier besprochen wird die Funktion expect_pass (vgl. ?expect_pass), die einfach alle shinytest-Snapshots vergleicht und über Abweichungen informiert. Das erlaubt zwar schnelle Vergleiche, aber ist weniger detailliert und spezifisch als der hier vorgestellte Ansatz.

Shiny-Apps mit shinytest & testthat testen

shinytest verfügt über die Klasse ShinyDriver (vgl. ?ShinyDriver), die beim Erstellen eines neuen Objekts die Shiny-App in einer neuen R-Session sowie eine Instanz von PhantomJS öffnet und diese automatisch mit der Shiny-App verbindet. PhantomJS ist ein Headless Webbrowser, der durch JavaScript bedient werden kann. Das ShinyDriver-Objekt ist mit verschiedenen Methoden ausgerüstet, die vor allem das Auslesen bzw. Eingeben von Werten für verschiedene Variablen in der shiny-App ermöglichen. Man kann also den Input-Variablen beliebige Werte gezielt, “manuell” (ohne das übliche User-Interface der Shiny-App) zuweisen und dann die Ausgabe-Variablen auslesen.

Beispiel eines Tests

In folgendem Test wird die Variable num_input auf 30 gesetzt und dann getestet, ob die Variable text_out zum String “Das Quadrat der Zahl n lautet: n² = 900” wird. Mehr zum Testen mit testthat ist hier zu finden.

Mit den Erwartungsfunktionen des Pakets testthat ist es also bequem möglich, die Funktionalitäten der Shiny-App zu testen. Ein Vorteil dabei ist auch, dass beim Aufrufen von devtools::test() sowohl die Tests der Shiny-App als auch die weiteren Unit-Tests mitberücksichtigt werden.

Tiefere Einsichten – Exportierte Variablen und HTML-Widgets

Innerhalb der server-Funktion von Shiny kann man zudem neue Variablen (außer der üblichen Inputs und Outputs) extra definieren. Diese sind dann von shinytest-Seite “sichtbar” und erlauben eine detailliertere Untersuchung der App-Abläufe. Als Beispiel für die oben gezeigte Shiny-App kann man die Liste aller eingegebenen Zahlen n speichern und als Variable inputs_list exportieren (bitte siehe den Code unten).

Für verschiedene HTML-Widgets bietet sich die Methode findElement mit der XPath zu verwenden app$findElement(xpath = "Hier das XPATH"). Wenn man beispielsweise Benachrichtigungen mit der Funktion showNotification() in der Shiny-App zeigt, kann man sie mit xpath = "//*[@id=\"shiny-notification-panel\"]" identifizieren und entsprechend testen.

Im Folgenden wird gezeigt, wie man in der Shiny-App eine Variable exportiert und Benachrichtigungen mittels showNotification() Benachrichtigungen darstellt:

Ein Test kann dann beispielsweise wie folgt aussehen: