✨ More modeling

content/04-produkte/3-multimode.tex

@@ -46,9 +46,7 @@ \subsubsection{Gesamtkosten}
 \subsection{Auswahl}
 Im Bereich Multimode gibt es nur einen zu vergleichenden Dienst, weshalb Abzüge nicht auf relativen Kriterien zu den anderen Diensten basieren, sondern auf absoluten Abzügen.
 \input{content/04-produkte/vergleiche/multimode-vergleich}
-Im Folgenden werden die Einstufungsentscheidungen, die in \autoref{tab:bewertungsmatrix-multimode} zu sehen sind, erläutert.
-
-So ist beispielsweise klar, dass zwar bei \AWSIOT{} Analytics die Jupyter Notebooks plattformunabhängig sind, aber die \ac{SQL}-Statements nicht übertragbar sind und, da zwingend ein \AWSIOT{} Core Broker benötigt wird. Aufgrund dieses \textit{vendor-lockins} kann ein großer Teil des Setups nicht übertragen werden.
+Klar ist, dass zwar bei \AWSIOT{} Analytics die Jupyter Notebooks plattformunabhängig sind, aber die \ac{SQL}-Statements nicht übertragbar sind und zwingend ein \AWSIOT{} Core Broker benötigt wird. Aufgrund dieses \textit{vendor-lockins} kann ein großer Teil des Setups nicht übertragen werden.
 \AWSIOT{} Analytics integriert sich gut mit anderen Dienstleistungen von AWS, z.B. mit \AWSIOT{} Core und den anderen \AWSIOT{} Diensten, SageMaker, QuickSight , Lambda, \ac{SNS} und weiteren.
 \AWSIOT{} Analytics ist speziell für \ac{IoT} Daten gebaut, weshalb Funktionalitäten eingebaut sind, die speziell in Kombination mit den anderen \AWSIOT{} Diensten Sinn machen. Die Verwendung dieser Funktionalitäten ist aber nicht zwingend notwendig. Es können auch andere Daten, z.B. IT-Monitoring eingespeist werden, wenn sie über \ac{MQTT} und den \AWSIOT{} Core Broker geladen werden.
 Die Erweiterbarkeit ist gegeben durch die Möglichkeiten, die \ac{SQL} in Verbindung mit der generischen Programmierbarkeit der Notebooks bietet und zusätzlich dadurch, dass durch die integrierte Datenbank Daten erneut mit anderer Logik verarbeitet werden können.

content/05-modellierung/1-anforderungserhebung.tex

@@ -1,4 +1,4 @@
-Wie in \autoref{theorie:referenzmodellierung} beschrieben, müssen Referenzmodelle einen subjektiven Empfehlungscharakter besitzen, damit sie akzeptiert und wiederverwendet werden. Dafür muss ein Abgleich mit den Anforderungen der Nutzenden geschehen. Um dies zu erreichen, wurden im Anhang transkribierte Interviews (vgl. \anhangref{anhang:interview-philipp-22.03.2021}, \anhangref{anhang:interview-peter-24.03.2021}, \anhangref{anhang:interview-ralph-24.03.2021}) durchgeführt. Daraus ergibt sich das in \autoref{abb:TopLevelEchtzeitRA} gezeigte Diagramm, welches die Anforderungen der individuellen Stakeholder an Dekompositiontiefe, Anwendbarkeit und Allgemeingültigkeit darstellt.
+Wie in \autoref{theorie:referenzmodellierung} beschrieben, müssen Referenzmodelle einen subjektiven Empfehlungscharakter besitzen, damit sie akzeptiert und wiederverwendet werden. Dafür muss ein Abgleich mit den Anforderungen der Nutzenden geschehen. Um dies zu erreichen, wurden im Anhang transkribierte Interviews (vgl. \anhangref{anhang:interview-philipp-22.03.2021}, \anhangref{anhang:interview-peter-24.03.2021}, \anhangref{anhang:interview-ralph-24.03.2021}) durchgeführt. Daraus ergibt sich das in \autoref{abb:TopLevelEchtzeitRA} gezeigte Diagramm, welches die Anforderungen der individuellen Stakeholder an Dekompositionstiefe, Anwendbarkeit und Allgemeingültigkeit darstellt.
 
 \begin{figure}[H]
 \centering

content/05-modellierung/2-echtzeitverarbeitung.tex

@@ -80,11 +80,6 @@ \subsection{Anforderungen}
 \item Anwendbarkeit auf Sensordaten (\ac{IoT})\\
 Kinesis ist generalisiert ausgelegt, durch die Integration mit \AWSIOT{} Core wird jedoch die Verarbeitung von \ac{IoT} Daten leicht gemacht. 
 
-\item Wertschöpfung für das Unternehmen wichtig\\
-\TodoW{Interview}
-Siehe \anhangref{anhang:interview-philipp-xx.04.2021}
-\item akzeptabel und problemlösend für Domäne\\
-\TodoW{ausfüllen}
 \item Handling von Events, Messwerten und \enquote{Streaming}\\
 Da die Verarbeitungslogik in Kinesis Data Analytics selbst zu schreiben ist, ist die unterschiedliche Behandlung von Events, niedrigfrequenten Messwerten und Streaming implementierungsabhängig. Dabei wäre es zu empfehlen ein Attribut in die übermittelten Nachrichten einzufügen, welches den geanauen Typ der Nachricht definiert und entsprechende Verarbeitungslogiken vereinfacht. Zu diesem Zweck soll das Attribut \mintinline[breaklines]{json}{{"messageType": "<string>"}} dienen. Für Events, die Definitionsgemäß keinen Messwert beinhalten, ist das Attribut mit dem Wert \mintinline[breaklines]{json}{{"messageType": "event"}} zu belegen. Messwerte sollen \mintinline[breaklines]{json}{{"messageType": "meas_low_freq"}} als Wert verwenden. Für hochfrequentes Streaming ist \mintinline[breaklines]{json}{{"messageType": "meas_high_freq"}} zu verwenden.
 

content/05-modellierung/main.tex

@@ -3,8 +3,25 @@ \chapter{Modellierung}
 \section{Anforderungserhebung}
 \input{content/05-modellierung/1-anforderungserhebung}
 
-\section{Echtzeitverarbeitung}
+\section{Echtzeitverarbeitung}\label{chap:ra-rt}
 \input{content/05-modellierung/2-echtzeitverarbeitung}
 
 \section{Batch Verarbeitung}
-\input{content/05-modellierung/3-batch}
+\input{content/05-modellierung/3-batch}
+
+\section{Einsatzszenarien der Referenzarchitekturen}
+Im Folgenden soll beleuchtet werden, wofür sich welche der beiden entwickelten Referenzarchitekturen besser eignet.
+Für das Monitoring eignet sich die in \autoref{chap:ra-rt} beschriebene Referenzarchitektur besser, da eine enge Integration sowohl mit CloudWatch Metrics als auch CloudWatch Logs besteht. So lassen sich Analysen zu in der \ac{AWS}-Cloud laufenden Workloads einfach durchführen.
+
+\TodoW{Vergleich RA - Deadline 03.05.}
+
+\begin{itemize}
+\item Wertschöpfung für das Unternehmen wichtig\\
+\TodoW{Interview}
+Siehe \anhangref{anhang:interview-philipp-xx.04.2021}
+\item akzeptabel und problemlösend für Domäne\\
+\TodoW{ausfüllen}
+\end{itemize}
+
+Da die Referenzarchitekturen als verteilte Systeme mit mehreren Diensten diverse Fehlerquellen haben können, die sich dann symptomatisch in den gezeigten Metriken bemerkbar machen, sind genaue Tests zum Verständnis der fehlerzustände wichtig. Im Rahmen des \textit{Chaos Engineerings} lassen sich gezielt Fehler in das System einführen um die Resilienz gegenüber diversester Fehlerquellen zu testen.\footcite[Vgl.][]{Augsten.2020} Bei den vorgestellten Referenzarchitekturen ist es zu empfehlen, regelmäßige Chaos Experimente durchzuführen um gezielt Fehlerszenarien wie doppelte Nachrichten, hohe Latenzen zwischen Diensten oder die temporäre Nichtverfügbarkeit einzelner Dienste zu simulieren und gezielt den Einfluss messen zu können. Folgend können Erkentnisse für den besseren Betrieb einer resilienten Dateninfrastruktur abgeleitet udn dokumentiert werden. Für \ac{AWS} gibt es den Dienst Fault Injection Simulator, welcher Fehler in Schnittstellen zwischen Diensten erzeugen kann und gezielt auch einzelne Infrastrukturkomponenten beeinträchtigen kann.\footcite[Vgl.][]{Barr.2021b} Unter Verwendung dieses Dienstes ist es möglich, die beschriebenen Chaos Experimente durchzuführen.
+

content/06-schluss/main.tex

@@ -6,4 +6,6 @@ \section{Fazit}
 \section{Handlungsempfehlung}
 
 \section{Ausblick}
+Innerhalb dieser Arbeit wurden Referenzarchitekturen für die Verarbeitung in der Cloud konstruiert. Ein Trend, der dabei ausgespart wurde, weil sich wichtige Komponenten nicht in der Cloud befinden, ist das sogenannte \enquote{Fog computing}. Nach der Definition von \citeauthor{Vaquero.2014} ist Fog computing ein Szenario, in dem heterogene, allgegenwärtige und dezentralisierte Geräte kommunizieren und kooperieren um Speicher- und Verarbeitungsaufgaben zu übernehmen.\footcite[Vgl.][30\psq]{Vaquero.2014} In der Praxis führt dies dazu, dass Verarbeitungsaufgaben in Teilen, angelehnt an das \enquote{Edge computing} von der Cloud in Richtung der Geräte ausgelagert wird.\footcite[Vgl.][]{Bonomi.2012} Dies geschieht dabei beispielsweise an Netzwerkgateways, die sowieso mit der Cloud kommunizieren und folgend nur noch bereits ausgewertete Daten übertragen. \ac{AWS} bietet mit dem Dienst Greengrass bereits eine Softwareplattform an, die auf diversen qualifizierten Gateways läuft.\footcite[Vgl. auch im Folgenden][]{AmazonWebServicesInc..o.J.bu} Durch die lokale Ausführung von Code könnten Schwachstellen adressiert werden, wie beispielsweise schlechte Netzkonnektivität. So kann Code, der auf Greengrass ausgeführt wird in Form von Containern oder lokalen Lambdafunktionen Benachrichtigungen lokal ohne Konnektivität zur Cloud versenden und beispielsweise Aktoren auslösen. Dies würde die gezeigten Referenzarchitekturen ergänzen. Dass mit Greengrass Anomaliedetektion möglich ist, wurde auch von \citeauthor{Shankar.2020} gezeigt.\footcite[Vgl.][]{Shankar.2020}
 
+Publikation intern - Confluence (und ggf. GitHub?)

content/anhang/10-db-ra-code.tex

@@ -1,10 +1,5 @@
 \anhang{Batch Referenzarchitektur Lambda Codebeispiel}\label{anhang:batch-codesample}
 Folgend wird eine von \anhangref{anhang:echtzeit-codesample} abgewandelte Lambdafunktion gezeigt, die mit Timestream interagiert.
-% \begin{listing}[H]
-% \inputminted[frame=lines,breaklines=true]{javascript}{code/sample-realtime-lambda.js}
-% \caption{Beispielcode zum versenden von Alarmen und automatischer Aktion}
-% \label{listing:sample-realtime-alarm-action}
-% \end{listing}
 
 \inputminted[frame=lines,breaklines=true]{javascript}{code/sample-db-lambda.js}
 \begin{listing}[H]

content/anhang/3-ralph.tex

@@ -29,15 +29,32 @@
 
 \LF Wir haben ja jetzt schon ein wenig Richtung \ac{IIoT} Daten geschaut. Speziell die Problematik mit den Auswertungen ist da wichtig. Entsprechend dem Datenhalbwertszeitmodell hat es ja drei verschiedene Entscheidertypen, die Daten in unterschiedlicher Zeit benötigen und Entscheidungen treffen. Taktische Entscheider brauchen Daten sehr schnell und trifft auch schnell Entscheidungen. Operative Entscheider brauchen Daten nicht unbedingt nahe Echtzeit und haben einen erweiterten Entscheidungshorizont auf Tage oder Wochen. Strategische Entscheider haben einen wesentlich größeren Entscheidungshorizont gleichzeitig aber auch geringere Anforderungen an die \enquote{Echtzeitigkeit} der Daten. Welche siehst du denn als am wichtigsten an oder für welche würdest du im \ac{IoT} Bereich optimieren?
 
-\RB Ich denke die sind alle gleich wichtig. Im operativen Entscheidungsmodus sollten die Entscheidungsregeln idealerweise automatisiert sein. Einen ausgelösten Feuermelder mit einer Email an einen Verantwortlichen zu koppeln, macht weniger Sinn, als beispielsweise die Werksfeuerwehr zu rufen.
+\RB Ich denke die sind alle gleich wichtig. Im operativen Entscheidungsmodus sollten die Entscheidungsregeln idealerweise automatisiert sein. Einen ausgelösten Feuermelder mit einer Email an einen Verantwortlichen zu koppeln, macht weniger Sinn, als beispielsweise die Werksfeuerwehr zu rufen. Bei unseren bisherigen Projekten ist Latenz nicht so wichtig - da die Geräte bei Bedarf Nachrichten senden oder in Intervallen von 50/60 Sekunden. Latetnz wird aber wieder wichtig, wenn man beispielsweise einen Wassersensor hat, der eine Aktion in der Businesslogik auslöst, die das Wasser bei Kontakt abstellt. Von den historischen Daten kann man ein Dashboard befüllen, wo ein Entscheider einmal die Woche drüberschaut und Entscheidungen trifft. Dann gibt es noch langfristige Usecases - Billing Daten beispielsweise interessieren den Kunden nur einmal im Monat.
 
-\TodoW{fertig machen}
+\LF Okay, verstehe. Ein bisschen von der Technik weg - es gibt ja Qualitätskriterien zu Referenzarchitekturen - die hatte ich dir schon gesendet. Wie siehst du denn die?
+
+\RB Ich bin da noch eher klassisch. Wenn du jetzt die ISO 9126 anschaust für Qualität von Softwaresystemen (\textit{siehe \autoref{abb:ISO9126}}), hast du noch ein paar andere Kriterien. Was ist denn zufriedenstellende Qualität? Wenn der Kunde zufrieden ist, ist es dann zufriedenstellend? Qualitätsmerkmale sind immer schwammig, weil es nicht \enquote{die Qualität} gibt. Es gibt nur eine passende Architektur, die eine passt besser, die andere schlechter. Qualität ist nicht absolut, sondern relativ anhand von Kriterien. 
 
 \begin{figure}[H]
 \centering
 \includegraphics[width=\textwidth]{graphics/ISO-9126.pdf}
-\caption[Qualitätskriterien nach ISO9126]{Qualitätskriterien nach ISO9126.\footnotemark}
+\caption[Qualitätskriterien nach ISO 9126]{Qualitätskriterien nach ISO 9126.\footnotemark}
 \label{abb:ISO9126}
 \end{figure}
 \footnotetext{Mit Änderungen entnommen aus: \cite{Johner.2018}}
 
+\LF Ja, für mich gehts darum zu erfahren, welche Kriterien da für den maximierten Nutzen für unsere Zielstakeholder am wichtigsten sind.
+
+\RB Übertragbarkeit zwischen Usecases ist wichtig. Gleichzeitig muss man aber schauen, dass man sich nicht zu sehr fokussiert auf ein Qualitätskriterium. Wenn man beispielsweise bewusst auf single-instance Datenbanken verzichtet und diese immer im Cluster errichtet, erhöht das die Zuverlässigkeit, sprengt aber vielleicht den Preisrahmen des Usecases. 
+
+\LF Da möchte ich mit den Variationspunkten ansetzen, wo ich Entscheidungsoptionen aufzeige wie man die Referenzarchitektur instanziieren kann.
+
+\RB Das Problem ist ja, dass man meistens mit mehr Qualitätskriterien, die man berücksichtigt das Resultat teurer wird.
+
+\LF Da macht das KISS Prinzip dann eher Sinn, oder?
+
+\RB Genau. Der Kunde sollte halt immer den Mehrwert sehen hinter den extra Features die man implementiert. Achte auch auf die Zuverlässigkeit und Modifizierbarkeit.
+
+(0:30)
+\TodoW{fertig machen}
+

content/anhang/4-philipp.tex

@@ -3,9 +3,11 @@
 \begin{tabularx}{\textwidth}{|l|X|}
 \hline
     Datum                  & xx.04.2021 \\ \hline
-    Thema                  & Review Referenzarchitektur \\ \hline
+    Thema                  & Review Referenzarchitekturen \\ \hline
     \begin{tabular}[c]{@{}l@{}}Teilnehmende,\\ Position\end{tabular} & \begin{tabular}[c]{@{}l@{}}Lukas Fruntke, Verfasser\\ Philipp A., Cloud Solution Architekt - \ac{NCS}\end{tabular}\\ \hline
 \end{tabularx}
 % \caption{Interviewübersicht Philip A.}
 % \label{tab:interviewuebersicht-philipp-xx.04.2021}
-\end{table}
+\end{table}
+
+\TodoW{transkribieren}

includes/abkuerzungen.tex

@@ -15,6 +15,7 @@ \chapter*{Abkürzungsverzeichnis}
  \acro{EMR}{Elastic Map Reduce}
  \acro{ETL}{Extract, Transform, Load}
  \acro{FaaS}{Function as a service}
+ \acro{HDD}{Hard Disk Drive}
  \acro{IaaS}{Infrastructure as a Service}
  \acro{IIoT}{Industrial Internet of Things}
  \acro{IoT}{Internet of Things}
@@ -39,6 +40,7 @@ \chapter*{Abkürzungsverzeichnis}
   \acro{SQS}{Simple Queue Service}
  \acro{S3}{Simple Storage Service}
  \acro{UDF}{User Defined Function}
+ \acro{UTC}{Universal Time Coordinated}
  \acro{VPC}{Virtual Private Cloud}
 \end{acronym}
 

includes/literatur-db.bib

@@ -193,6 +193,14 @@ @online{AmazonWebServicesInc..2020f
     urldate = {2021-04-29}
 }
 
+@online{AmazonWebServicesInc..2020g,
+    editor = {{Amazon Web Services, Inc.}},
+    year = {2020},
+    title = {{Amazon Timestream is now Generally Available}},
+    url = {https://aws.amazon.com/about-aws/whats-new/2020/09/amazon-timestream-now-generally-available},
+    urldate = {2021-05-02}
+}
+
 @online{AmazonWebServicesInc..2021,
     editor = {{Amazon Web Services, Inc.}},
     year = {2021},
@@ -201,6 +209,14 @@ @online{AmazonWebServicesInc..2021
     urldate = {2021-04-10}
 }
 
+@online{AmazonWebServicesInc..2021b,
+    editor = {{Amazon Web Services, Inc.}},
+    year = {2021},
+    title = {{Amazon SNS unterst{\"u}tzt jetzt 1-Minuten-CloudWatch-Metriken}},
+    url = {https://aws.amazon.com/de/about-aws/whats-new/2021/01/amazon-sns-now-supports-1-minute-cloudwatch-metrics},
+    urldate = {2021-05-02}
+}
+
 @online{AmazonWebServicesInc..24.04.2021,
     year = {24.04.2021},
     title = {{Stream CloudWatch Logs to Kinesis}},
@@ -554,6 +570,87 @@ @online{AmazonWebServicesInc..o.J.bl
     urldate = {2021-05-01}
 }
 
+@online{AmazonWebServicesInc..o.J.bm,
+    editor = {{Amazon Web Services, Inc.}},
+    year = {nodate},
+    sortyear = {1},
+    title = {{Grafana - Amazon Timestream}},
+    url = {https://docs.aws.amazon.com/timestream/latest/developerguide/Grafana.html},
+    urldate = {2021-05-02}
+}
+
+@online{AmazonWebServicesInc..o.J.bn,
+    editor = {{Amazon Web Services, Inc.}},
+    year = {nodate},
+    sortyear = {1},
+    title = {{Amazon QuickSight Pricing}},
+    url = {https://aws.amazon.com/quicksight/pricing},
+    urldate = {2021-05-02}
+}
+
+@online{AmazonWebServicesInc..o.J.bo,
+    editor = {{Amazon Web Services, Inc.}},
+    year = {nodate},
+    sortyear = {1},
+    title = {{Amazon Managed Service for Grafana Pricing}},
+    url = {https://aws.amazon.com/grafana/pricing/?nc=sn&loc=3},
+    urldate = {2021-05-02}
+}
+
+@online{AmazonWebServicesInc..o.J.bp,
+    editor = {{Amazon Web Services, Inc.}},
+    year = {nodate},
+    sortyear = {1},
+    title = {{Storage - Amazon Timestream}},
+    url = {https://docs.aws.amazon.com/timestream/latest/developerguide/storage.html},
+    urldate = {2021-05-02}
+}
+
+@online{AmazonWebServicesInc..o.J.bq,
+    editor = {{Amazon Web Services, Inc.}},
+    year = {nodate},
+    sortyear = {1},
+    title = {{Query - Amazon Timestream}},
+    url = {https://docs.aws.amazon.com/timestream/latest/developerguide/queries.html},
+    urldate = {2021-05-02}
+}
+
+@online{AmazonWebServicesInc..o.J.br,
+    editor = {{Amazon Web Services, Inc.}},
+    year = {nodate},
+    sortyear = {1},
+    title = {{Supported data types}},
+    url = {https://docs.aws.amazon.com/timestream/latest/developerguide/supported-data-types.html},
+    urldate = {2021-05-02}
+}
+
+@online{AmazonWebServicesInc..o.J.bs,
+    editor = {{Amazon Web Services, Inc.}},
+    year = {nodate},
+    sortyear = {1},
+    title = {{Writes}},
+    url = {https://docs.aws.amazon.com/timestream/latest/developerguide/metering-and-pricing.writes.html},
+    urldate = {2021-05-02}
+}
+
+@online{AmazonWebServicesInc..o.J.bt,
+    editor = {{Amazon Web Services, Inc.}},
+    year = {nodate},
+    sortyear = {1},
+    title = {{Data Modeling - Timestream}},
+    url = {https://docs.aws.amazon.com/timestream/latest/developerguide/data-modeling.html},
+    urldate = {2021-05-02}
+}
+
+@online{AmazonWebServicesInc..o.J.bu,
+    editor = {{Amazon Web Services, Inc.}},
+    year = {nodate},
+    sortyear = {1},
+    title = {{AWS IoT Greengrass Features}},
+    url = {https://aws.amazon.com/greengrass/features},
+    urldate = {2021-05-02}
+}
+
 @online{AmazonWebServicesInc..o.J.c,
     year = {nodate},
     sortyear = {1},
@@ -691,7 +788,7 @@ @online{AmazonWebServicesInc..o.J.q
     sortyear = {1},
     title = {{Amazon Timestream Pricing}},
     url = {https://aws.amazon.com/timestream/pricing},
-    urldate = {2021-04-07}
+    urldate = {2021-05-02}
 }
 
 @online{AmazonWebServicesInc..o.J.r,
@@ -880,6 +977,15 @@ @online{Barr.2021
     urldate = {2021-04-30}
 }
 
+@online{Barr.2021b,
+    author = {Barr, Jeff},
+    editor = {{Amazon Web Services, Inc.}},
+    year = {2021},
+    title = {{AWS Fault Injection Simulator -- Use Controlled Experiments to Boost Resilience}},
+    url = {https://aws.amazon.com/blogs/aws/aws-fault-injection-simulator-use-controlled-experiments-to-boost-resilience},
+    urldate = {2021-05-02}
+}
+
 @article{Bartos.2019,
     author = {Bartos, Matthew and Mullapudi, Abhiram and Troutman, Sara},
     year = {2019},
@@ -1743,6 +1849,14 @@ @online{Penz.2020
     urldate = {2021-04-17}
 }
 
+@online{Pochiraju.2020,
+    author = {Pochiraju, Tej},
+    year = {2020},
+    title = {{From Metal To Alerts With AWS IoT, Timestream and QuickSight}},
+    url = {https://dev.to/tejpochiraju/from-metal-to-alerts-with-aws-iot-timestream-and-quicksight-2b5b},
+    urldate = {2021-05-02}
+}
+
 @online{Pogosova.28.05.2020,
     author = {Pogosova, Anahit},
     year = {2020},
@@ -1822,6 +1936,14 @@ @thesis{Reidt.2019
     titleaddon = {Lehrstuhl f{\"u}r Wirtschaftsinformatik}
 }
 
+@online{Riddle.2021,
+    author = {Riddle, Jason and Patana-anake, Tiratat},
+    year = {2021},
+    title = {{Export cloudwatch metrics to timestream {\#}16}},
+    url = {https://github.com/awslabs/amazon-timestream-tools/issues/16},
+    urldate = {2021-05-02}
+}
+
 @online{Robinson.2017,
     author = {Robinson, David},
     editor = {{Stack Overflow}},