wie geht es da irgendwie 650, wie es sonst wären,
glaube ich, oder noch viel mehr wären hätte,
sondern nur nicht die Handform,
wie kann ich jetzt eine Handform auswählen,
kann sie hier rüberziehen und der Gebärde hinzufügen ist.
Liegt sie da? Jetzt kann ich sie auswählen und an
ihr Manipulation vollziehen. Ich kann die normale Rotationsgeste vollziehen,
das sieht man jetzt, die Leute hätte ich auf dem Dings oder
nur hier bei mir auf dem iPad und kann sie hier rotieren.
Reißt, ich verändere die Stellung in dieser, in dieser Ebene.
Jetzt kann ich swipen und verändere dadurch die Füllung. Füllung verändern,
bedeutet, ich verändere die Stellung in dieser Ebene. Schwarz bedeutet,
ich sehe die Hand Rückseite, weiß bedeutet,
ich sehe die Hand innenfläche und halb schwarz,
halb weiß, heiß, ich sehe die Handkante,
also das bin ich schon so.
Jetzt die einzige Ebene noch fehlt, ist halt diese Ebene und das
wird in der Gebärdenschrift dargestellt durch eine kleinen Spalt in dem Handzuholen.
Und das mache ich durch einen vertikalen, einen Holzenthalt-Swipe,
also einmal so wischen. Und das ist so praktisch,
sag ich mal, Kernidee meiner Diplomarbeit,
die Komplexität der Symbolauswahl zu verringern,
durch direkte Manipulation der einzelnen Symbole
Was ich zusätzlich noch gemacht habe, um die Auswahl ein
bisschen zu verringern, ist, ich habe mir angeguckt,
wir haben ja ein riesengroßes Wörterbuch mit 18.000 Eintragungen schon,
der deutschen Gebärdenschrift.
Ich habe geguckt, wie oft kommen denn überhaupt welche Symbole vor?
Gerade bei Hanssymbolen gibt es, glaube ich, anhandform 650 insgesamt.
Und ich habe angeguckt, wie viele werden von diesen Handformen
denn eigentlich genutzt in der deutschen Gebärdensprache? Und ich bin darauf gekommen,
dass im Grunde nur diese, die angezeichnet, das sind,
glaube ich, insgesamt ungefähr um die 80 Stück,
nicht ganz 76 Stück, dass die wirklich oft vorkommen.
Ich habe einfach geguckt, welche Handform kommt öfter als zehnmal
vor in diesen 18.000 Gebärden? All die weniger als zehnmal vorkommen,
habe ich gesagt, die sind so selten,
die braucht man gar nicht oft,
die muss ich auch
gar nicht anzeigen
Natürlich sollte es auch irgendwann mal eine Möglichkeit haben,
auf die zuzugreifen, weil es gibt ja anscheinend doch irgendwelche Gebärden,
wovon man sie braucht.
Aber im Grunde, für die meisten Fälle, 99 Prozent,
sag ich mal, decke ich einfach damit ab,
dass ich hier diese Auswahl von Handform habe.
Jetzt kann ich hier die Handform auswählen.
Ich kann aber auch zum Beispiel ein Mundbild auswählen.
Ich kann Bewegungspfeile auswählen, Satzzeichen und noch weitere Kategorien.
Ich kann noch ein paar Operationen an den Dingen ausführen.
Ich kann spiegeln, ich kann es duplizieren und so weiter
und so fort. Ich kann Variationen auswählen. Genau,
das ist im Grunde
die App
Mit der ich jetzt, wenn ich auf Speichern drücke,
ich bin jetzt hier gar nicht online, diese Gebärde speichern kann.
Und sie landet bei uns im Wörterbuch für den Delex-Editor. Das heißt,
da kann ich jetzt, ich schweigere sie unter irgendeinem Namen und sollte genau
dem Namen, kann ich sie dann später im Delex-Editor,
im Dokumenten-Editor abrufen und dort benutzen und in mein Dokument einbauen.
Also der Service ist, die Jürgen jetzt gerade bekannt hat.
Richtig, genau. Es ist ein technischer Service davor,
ein Surflet, weil das ist halt die Technik,
mit der man kommunizieren kann,
aber dahinter wird halt einer der fachlichen Services aufgerufen,
gesagt,
das heißt dann irgendwie safe signe,
also Speichergebärde und der speichert die Gebärde im Wörterbuch ab
Ja, schön gesprochen haben, ist also diese Service-Architektur,
also zwischen Frontend und dem fachlichen Service,
das da typischerweise noch so ein Interaktions-Service-Schicht, dazwischen,
ich bin das, denke ich, genau so ein Beispiel,
da eben noch so eine Art von Übersetzungstechnik.
Genau, richtig, genau. Ich muss es ja irgendwie
auch über die Schnittstelle ja realisieren und alles und diese technischen einfach Herausforderungen zu meistern.
Aber der flachliche Service ist genau der gleiche,
den ich auch im Dealex-Editor im Dokumenten-E-Tor benutze.
Gut, das ist die Anwendung an sich,
sind dazu erstmal noch Fragen
Ja. Das würde ich auch selbst sagen, zum Wohl zu zeichnen.
Und er regt da im Gefechtsbrot und meinte, ist das so?
Ja, habe ich auch überlegt, anfangen,
sowas zu machen. Ist natürlich ein bisschen anderer Herangehensweise,
ist aber, glaube ich, auch sehr komplex,
weil es halt ihn doch sehr viele Symbole auch gibt,
weil es halt, ich kann mir gut vorstellen,
dass da schnell zu Missverständnissen kommt.
Gerade wenn man jetzt manchmal unterscheiden möchte, zwischen so und so,
dass es da so, dass es schwierig wird.
Aber die Idee hatte ich auch so ungefähr. Gut,
und jetzt, wo ich da gerne was zur Architektur sagen von der Anwendung,
denn auch hier handelt es sich wieder um eine Wärmearchitektur im Hintergrund.
Und davon muss ich wieder einmal
hier wechseln
Musik Genau, einmal wollte ich noch, bevor ich jetzt
zur Architektur komme, zur iOS-Entwicklung, generell was sagen.
Es ist so, Apple möchte halt gerne,
wenn man für ihre Geräte entwickelt, dass man auch ihre Produkte dafür nutzt.
Also kann man nur auf einem Mac für iOS entwickeln.
Es geht nicht, dass ich meinen normalen Windows-Rechner nehme und
da eine Entwicklungsumgebung installiere und dafür dann für iOS entwickel.
Das geht leider nicht. Ich brauche einen Mac und auf
diesem Mac brauche ich X-Code. Das ist die Entwicklungsumgebung,
die vorgeschrieben ist. Nur damit kann man Auch iOS-Programme entwickeln.
Wenn man vor jahrelang mit Eclipse gearbeitet hat,
dann ist es etwas gewöhnungsbedürftig dann auf einmal mit X-Code zu arbeiten.
Denn X-Code selbst als Entwicklungsumgebung ist noch nicht so stark ausgereift,
wie es jetzt Eclipse schon ist. So einfache Sachen wie,
ich nenne mal eine Klasse um und die wird dann überall für mich umbenannt im ganzen Code,
was ich normalerweise durch einen Shortcut mal ganz schnell mache und innerhalb ein Zwei-Sekunden-Ding ist,
das geht da nicht und es dauert dann eine halbe Stunde nur,
weil ich mal irgendwo mich verschrieben habe oder was umbenennen möchte.
Und das ist nur ein Beispiel,
es gibt mehrere solche Sachen, einfach dieses,
die das arbeiten mit X-Code einfach
ein bisschen schwieriger machen
Dann als Sprache vorgestiegen ist Objective Sea,
das ist eine Programmiersprache, die auf C basiert.
Jeder Objective Sea-Compiler kann auch normale C-Programme kompilieren und ich kann
auch alles nutzen, was man aus Tee schon kennt.
Man macht es aber im Grunde eigentlich nicht. Man arbeitet mit
den Konstrukten, die ein Objective Sea obendrauf gesetzt worden sind.
Objective Sea ist, wie der Name auch schon sagt, objektorientiert.
Also alles, was man so kennt, Vererbung,
solche ganzen Sachen, Problemophie, das ist alles,
das gibt alles auch, also Klassen und Objekte.
Das gibt es alles auch in Objective Sea
Was etwas anders ist, es gibt dynamische Typisierung.
Das ist etwas, was es in Java nicht gibt,
Dynamische Typisierung, da habe ich statische Typisierung. Das heißt,
wenn meine Klasse mein Objekt von dem Typ ist,
dann kann ich auch nur die Methoden an diesem Objekt aufrufen,
die dieser Typ hat.
Bei dynamischer Typisierung ist das nicht so. Ich kann im Grunde
an jedem Objekt jede Methode aufrufen, die ich möchte.
Das Konzept ist auch nicht hier Aufruhen von Methoden,
sondern ich sende dem Objekt eine Nachricht.
Und wenn er diese Methode hat, dann beabet er mir das.
Und wenn er diese Methode nicht hat,
dann macht er halt nichts
Äh, dynamische Besiegung ist auch in der Fachwelt eine sehr umstrittene Sache,
ob das was Gutes ist, ob das eher was Schlechtes ist.
Ich glaube, es gibt da noch keine wirkliche Einigung.
Es ist... Es sind diejenigen, die die Language Wars führen.
Kann sich da... Richtig, genau. Genau. Wo
ich jetzt nur greise. Ich stelle es mir jetzt nicht an.
Wenn du eine Nachricht schickst, die das Objekt nicht implementiert,
was tut es denn für dich nichts?
Oder sagt es, also, Nethod Notlanders, wie man das... Also,
man kann es so einbauen, dass dann eine Fehlermeldung auch zurückkommt,
aber man muss es halt explizit einbauen,
dass dann eine Fehlermeldung kommt.
Ansonsten macht es halt wirklich nichts
Und das ist einfach genau, das ist,
denke ich, finde ich zumindest sehr problematisch irgendwie,
weil man... Ja, das sehe ich nicht aus so.
Man hat auf der einen Seite mehr Flexibilität, mehr Freiheiten,
auf der anderen Seite natürlich auch, ist sehr viel fehleranfälliger, ja?
Das heißt aber auch, dass du gar keinerlei autokuptischen oder sowas haben kannst, oder? Doch,
gibt jetzt, also der Compiler, muss man dazu sagen,
der zeigt mir auch ein Warning an, wenn ich irgendwelche Methoden aufrufe, die es da nicht gibt. Aber es kompiliert und es läuft auch. Genau. Es gibt Audiokumplitionen,
gab es anfangs auch nicht,
als ich am Anfang mit X-Code gearbeitet habe,
gab es auch keine Autocompletion und das ist, naja,
gut, dann noch was, es gibt keine Gabels-Collection,
wie man das aus Java kennt, die einem die toten Objekte abräumt,
die niemand so mal referenziert werden, sondern man muss selbst einen Referenz-Counter-Hartmann,
den man hoch und runter zählen muss,
wenn man eine Referenz darauf führt auf ein Objekt,
dann zählt man das einen hoch,
wenn man es gerne behalten möchte und man sagt,
das brauchen wir nicht mehr,
nimmt mit dem Encounter einen runter und wenn es auf null liegt,
dann wird es irgendwann mal abgeräumt.
Aber man muss halt diesen Counter immer selbst mitzählen.
In der neuesten Version, glaube ich,
muss man das auch nicht mehr manuell tun,
sondern der Compiler baut einem diese Referenz-Count ein.
Aber ist trotzdem ein Unterschied. Genau,
das ist halt die Sprache,
mit der
ich arbeite
Dann gibt es noch den Interface-Builder,
was ein grafisches Werkzeug ist, um die Guise zu bauen.
Das ist mittlerweile ein Excode integriert. Das warst du früher
auch nicht, sondern das auch getrennt. Mittlerweile ist es
integriert und man verbindet dann praktisch die grafischen Elemente hat,
die man da baut in diesen Interface-Buildern nachher mit dem Code selbst.
Und in der Praxis ist es wirklich so,
im Grunde baut man auch die Guise zum Teil noch in diesem Interface-Builder,
aber dann macht man auch dann doch wieder sehr viel im Code selbst.
Weil da fehlt noch sehr viel geändert werden muss.
Gut, am einen Folie weiter
, bitte
Genau. Ähm... Bei der Architektur wird einem von,
äh, bei der RS-Entwicklung wird einem das, äh,
MVC-Pattern vorgeschrieben von der Entwicklungsumgebung und der Formentwicklungsart.
Wem sagt MVC was? Okay, das sind einige,
aber nicht alle, deswegen will ich es noch mal kurz erklären.
Also MVC, dabei handelt es sich um ein Muster,
ein Architekturmuster, nachdem man Anbindungen aufbauen kann,
steht da häufig ein Modelview,
Und sieht folgendermaßen aus. Also ich habe einen,
ich habe ein Modell praktisch, das würde bei Wann dem Material entsprechen,
meinen fachlichen Objekten aus der Fachdomäne, die dort abgebildet sind,
obwohl sie auch nicht unbedingt so fachlich sein müssen.
Es ist einfach das Datenmodell praktisch, was da eben zugrunde liegt.
Diese Daten, dieses Datenmodell, diese Daten werden dargestellt für eine View.
Das ist praktisch die UI, die benutzt dieses Modell und stellt dieses Star.
Die ganze Programmlogik liegt wiederum oben im Controller, arbeitet auf dem Modell,
führt darauf Operationen auf und Frankfurt ist auch Änderung an der View vornehmen.
Das sind halt die durchgezogenen langen Pfeile.
Und dann gibt es halt noch diese gestrichelten Pfeile.
Das ist praktisch das listende Konzert. Oder das Beobachter,
Muster, wem das was sagt. Das heißt,
wenn eine Änderung, wenn ich im View eine Eingabe mache,
also im UI, irgendeiner Form,
habe ich eine Touch-Operation mache oder ob ich halt auf einem Desktop-Rechner halt irgendwie die Maus bewege oder ob ich Enterdrücke,
wie auch immer, irgendeine Benutzerinteraktion,
dann wird das durch das Beobachter-Patter, den Controller mitgeteilt.
Der macht irgendwelche Operationen, irgendwelche Logik läuft ab
und kann dann passt dann praktisch das Modell an.
Und das Modell ist auch, auch wieder das Beobachter,
muss da, die View beobachtet praktisch das Modell.
Und da ändert sich was dran. Also werden diese Änderungen
im Modell dann dargestellt von der View. Genau, das
ist dieses klassische MVC. Dann nochmal eine Folie weiter.
Das MVC für iOS-Apps sieht ein bisschen anders aus,
sehr ähnlich. Aber wir sehen, der Unterschied ist,
dieses Beobachterpattern vom Modell zum View existiert hier nicht,
sondern es gibt ein Beobachterplättern vom Modell zum You Controller.
You Controller heißt auf einmal, nicht mehr Controller,
das ist so die Namen, die praktisch iOS-Entwicklung Apple davor gibt.
Für jedes View, für jede, für jedes UI-Darstellung,
im Grunde bei iPhone ist eine View immer ein Bildschirm und wenn ich rüberwechsel,
ist eine neue View, gibt es immer ein View-Controller.
Und im Hintergrund halt das Modell. Und der Ablauf hier ist halt
ein bisschen ein anderer. Hier kriege ich keine Hier ist es nicht so,
dass Änderung am Modell direkt die View beeinflussen,
sondern es muss immer über den Umweg des View Controllers gehen,
der dann praktisch dafür sorgen muss, dass das Modell und die View,
dass die beiden konsistent gehalten werden.
Gut, das ist so das, was mir iOS vorgibt,
erstmal die technische Seite mit X-Code Objective C und dem Interface-Builder
und dann dieses MVC-Pattern, was ich benutzen muss,
die Grundarchitektur, die ich mit anderen bauen muss.
Dann einmal weiter. Aber wir möchten ja gerne unsere Anwendung
in Wammen bauen. Deswegen habe ich mich damals,
als ich so ungefähr die Anforderungen dafür definiert hatte für meinen iPad,
er hat erstmal hingesetzt, geguckt,
Was kann ich denn so identifizieren an warmen Objekten,
die ich habe?
Also was sind meine Werkzeuge? Was sind meine Materialien?
Was sind meine Services? Was sind meine Fachwerte und so weiter?
Ich habe euch, die habe ich ja gerade eben gezeigt,
am Anfang habe ich erst mal ein Werkzeug,
mit dem das Wörter, mit dem das gesamte Wörterbuch angezeigt wird.
Also ein Wörterbuch Viewer, wenn man so will,
in dem man das ganze Wörterbuch dargestellt werden kann,
in dem man durchs Grollen kann.
Das wäre ein Werkzeug. Dann habe ich auf ein Gewerte
raufgetappt und ein neues Werkzeug ist aufgegangen,
der Gebärdendetailview,
habe ich
es hier mal genannt
Indem halt die Details angebärt angezeigt werden, was bedeutet das
genau, wer hat diesen Eintrag gemacht und so weiter.
Das war diese Ansicht noch nicht so ganz ausgereift.
Und dann habe ich als nächstes Werkzeug den Gebärden-Eto selbst,
der ist ja auch fett unterlegt,
weil das ist eigentlich hier so der Fokus,
darum soll es ja heute geben.
Der Gebärden-Aditor. Und der wiederum besteht aus zwei Subwerkzeugen.
Ihr habt ja gesehen, hier auf der linken Seite
hatte ich einmal die Möglichkeit, mir Symbole auszuwählen.
Das ist der Symbolauswähler, habe ich es mal genannt,
im Englischen Science-Selector-Symbolauswähler, klingt ein bisschen komisch.
Und auf der rechten Seite hatte ich halt die Editierfläche,
dass mein anderes Subwerkenzeug aus diesen beiden Zugwerkzeugen setzt sich dann
der Gebärden-Aditor komplett zusammen
Dann brauche ich im Hintergrund Services. Ich muss meine Symbole
irgendwo herbekommen, die kleinen Bildchen für die Symbole.
Dafür habe ich einen Simble Service und ich muss
meine Gewerden nachher irgendwo her abrufen können.
Und ich muss sie auch abspeichern können. Dafür habe ich dich
ein Sign Service. Das bin ich ein bisschen inkonsistent gewesen,
die oben war es deutlich, unten ist Englisch.
Aber ihr, ich denke, ich verstehe, worum es geht.
Ja, okay. So, letzte Woche auch immer.
Vater Peak ist den Fototypen und da gibt es daneben
auch hässer Artikel
Du hast mich ein bisschen geschätzt. Ja. Ja,
bitte. Genau, dann die Materialien. Da gibt es erstmal
ein Wörterbuch, gibt es sowas wie Dictionary-Entries, also Wörterbucheinträge.
Wir bleiben jetzt im Englischen. Die hütet an, gibt
es wiederum Science. Klar, Gebärden ist ein Material,
mit dem ich arbeite, was dabei werden muss,
was angezeigt wird und so weiter.
Das wiederum besteht aus positionierten Symbolen, also Symbolen,
die irgendwo eine Position haben auf der zweidimensionalen Fläche,
also die XY-Position,
wo steht dieses Symbol
Und dann habe ich halt Fachwerte, das Symbol selbst.
Denn Symbole selbst sind, die sind einfach da, so wie Buchstaben oder Zahlen.
Das sind keine Sachen, die ich verändern kann.
Sie bilden einfach einen Wert ab praktisch und werden halt oben benutzt. Genau,
das sind so die praktischen, die Grundelemente einer Wamm,
die ich erstmal identifiziert habe, bevor ich mir dann überlegt habe,
wie kann ich das System jetzt bauen, wenn nochmal eine Folie weitergeht?
Genau, und zwar haben, wie gesagt,
vorgeschrieben ist man ja, dieses MVC-Pattern, dieses iOS-MVC-Pattern,
mit dem ich meine Anwendungen bauen muss.
Dann nochmal eine weiter. Genau, und das sieht dann
bei mir so aus. Also ich habe einen,
ich habe Mein Modellion, das ist einfach mal Atemkürzt durch Modell.
Dann habe ich halt eine View, eine Simble-Selection-View, also die View,
die halt anzeigt, wo die ganzen Symbole drauf sind.
Und auf der anderen Seite habe ich ein Newtiple Sign View,
das ist diese Editierfläche. Das sind die beiden Gui-Elemente,
die es anzeigen. Und für beide habe ich hier sogar
noch auch einen Controller, genauso wie mir das iOS-Vorschreibt,
die halt die Logik für diese beiden Sachen beherbergen und noch einen Übergeordneten.
Das wäre dann hier der Science-A-Tor, der im Hintergrund auch irgendwelche Services benutzt.
Und das ist halt genau, geschrieben vom iOS-Pattern.
Ich habe ein Model, ich habe ein View,
ich habe einen Controller. Jetzt kann man sich sie angucken,
sagen die euch, okay, das sieht schön aus,
aber eigentlich wollte ich eine Wammarchitektur haben.
Ist das jetzt schon Wamm oder nicht? Und jetzt machen wir
eine Folie weiter. Und ja, es ist so,
es ist einfach nur eine andere Sichtweise auf die Dinge.
MVC und Wamm widersprechen sich nicht gegenseitig,
sondern es ist einfach nur eine andere Sichtweise.
Ihr habt gesehen, die unterlegen auf einmal zurück und vor,
die unterlegenen Sachen verändern sich gar nicht.
Nur im Hintergrund ist einfach die Sichtweise anders. Aus meinem Modell
wird mein Material. Und was eben noch aufgeteilt war,
hier in View und oben Controller, hat ein bisschen anderen Schnitt bekommen.
Nämlich mein Controller und die View zusammen,
das bildet mein Material ab
Ähm, mein Werkzeug, sorry. Das ist mein Werkzeug, genau.
Und die erkennt man auch wieder genau die beiden. Subwerkzeuge,
äh, wieder, wie ich es eben erklärt habe,
einmal den, äh, Sign, äh, den,
äh, Simble, äh, Selector und dann halt meine,
meine Editierfläche, mein Mutable Sign, Viewer, Musiaville,
weil es Veränderer ist, die Wortwahl vielleicht nicht ganz so clever,
ähm, und das alles wird zusammengehalten durch das Oberwerkzeug,
den Gibären-Eto selbst, den Sign-Editor.
Und der benutzt im Hintergrund halt noch die fachlichen Services,
den Sign-Service und den Simble Service,
umsetzt den zu bedienen
Genau. Eine andere Programmiersprache passiert. Ja,
bei der Hoffnung,
dass man auf der Ebene schon geschafft wird,
mit Materialien, also vielleicht noch ein bisschen drauf so,
dass man so Funktionalität des Seinen Editors landet,
da in der Ruhe Ähnlichkeit ist zwischen denen,
dass man ein iPad baut,
was so mit GBT
für den Web basiert
Ja. Ja, ist richtig. Also die Funktionalität ist
im Grunde gleich, was natürlich unterschiedlich ist und die Interaktionsfonds.
So, bei meinem habe ich Maus und Tastatur. Beim anderen habe ich meinen Swipe und meinen Touch und hast du nicht gesehen. Alles,
denke ich, wenn überhaupt, also nicht mit dem behauptet,
aber das ist ja dann, denke ich,
so einer der Ruhmschaften von so einer Modellarchitektur,
würde es mir jetzt nicht nur Ähnlichkeiten,
also von Einarbeitung und dieses ganze Zeug, sondern dass die Tragfähigkeit,
der wird insgesamt der Architektur sich dadurch erweist,
dass es so, sagen wir mal, für Android,
Android-basiertes Edgerät.
Das müsste man nicht kauen, also bis drauf,
also in so Funktionskomponente des Gebärden-Editors eigentlich komplett.
Ich streiche die Funktionskomponente. Materialien und Service müsste man also komplett übernehmen können.
Ja, richtig, genau. Und das sieht man ja,
wie gesagt, auch daran,
dass zum Beispiel die fachlichen Service im Hintergrund eigentlich genau die gleichen sind,
die wir auch jetzt schon für unsere Dokumenten oder unseren Webgebärden-Editor benutzen.
Der fachliche Service ist der gleiche. Lust, dass der
auf dem iPad läuft. Ja, der ist ja
auch zum Teil auch auf dem Server dann wieder.
Das ist sogar derselbe. John ist derselbe,
derselbe ist es so,
Auf beiden Seiten. Und jetzt am Ende nur mal eine
Folie weitergeht, da kommen wir eigentlich auch zu unserem Fazit.
Wir sehen hier beide Architekturen, einmal eine Web-App als Wab-App
und einmal eine iPad-App als Wamm. Und jetzt ist natürlich die Frage,
was sind die Unterschiede, was sind die Gemeinsamkeiten zwischen Reiben?
Klar, es gibt große Unterschiede, einfach durch technische Gegebenheiten vorgegeben.
Ich bin gezwungen, MPOC zu benutzen und so weiter.
Ich brauche für ein View und ein Controller dafür.
Das sieht bei der Web-App ganz anders aus. Dafür habe ich
da wieder einen kleinen Surf-Serverschnitt, der an einer anderen Stelle liegt und so weiter.
Aber was das Schöne an Wamm ist halt,
Man kann trotzdem auf beide Sachen mit der Wammbrille raufgucken
und dann kann man mir die gleichen Sachen identifizieren,
die zwei einer Unterlinien-Ebene, wie wir sich unterscheiden,
aber durchwammen hat man halt die Möglichkeit,
beides zu vergleichen und auch wiederzuerkennen und wieder identifizieren im anderen System.
Und unser Fazit ist eigentlich,
dass ich halt wann auch für Web-Apps und für iOS-Apps sehr gut eignet,
um Anwendungen zu bauen und einfach auch eine gute Sicht- und Weltanschauung,
also gute Weltanschauungsmodell ist,
einfach um auf Dinge zu gucken und auch
die Fachlichkeit besser zu verstehen
Was habe ich jetzt für eine Diplomarbeit?
Super. Ja, danke. Ja,
du noch was zu ergänzen