Sind Event-Based Components (EBC) ne super Sache oder “krank” (wie gerade in einem Diskussionsforum behauptet wurde)? Tja… ich glaube natürlich, dass sie ziemlich cool sind und was bringen. Der Entwurf von Software wird damit einfacher, die Wartbarkeit, äh, Evolvierbarkeit steigt, die Verständlichkeit ebenfalls und automatisierte Tests brauchen keine Mock-Frameworks mehr.
Es gibt auch eine kleine Community um EBC, die dasselbe denkt. Die Majorität der Entwickler ist jedoch – wenn sie denn EBC überhaupt kennen – mindestens indifferent. Ist es deshalb aber besser, weiterzumachen wie bisher? Oder wären EBC ein Gewinn für sie? Wer hat nun recht? Und in welchen Fällen?
Ich glaube, da können wir Überzeugte uns noch lang den Mund fusselig reden und schreiben, am Ende zählt immer nur eine Gegenüberstellung. Wer die aber nicht kundig selbst macht oder machen kann, der wird nicht überzeugt. Also muss die Gegenüberstellung anders laufen. Sie muss präsentiert werden.
Deshalb möchte ich ein Angebot machen:
Wer glaubt, EBC brächten nichts oder würden irgendwie die Softwareentwicklung sogar noch behindern, der kann sich mit seinem Ansatz zur Planung von Software im fairen, harten aber herzlichen Wettstreit mit mir messen. Wie wäre das?
Das ist dann natürlich kein wissenschaftliches Experiment. Dennoch ließe sich was lernen. Auf beiden Seiten. Da bin ich mir sicher.
Ich schlage vor, dass ein solcher “Shoot Out” in einer .NET User Group stattfindet. Sicher gibt es eine, die den Event hosten würde. Diese User Group würde beiden Parteien – EBC und Non-EBC – eine Aufgabe stellen, die die dann in einer Timebox umsetzen müssen. Zeitaufwand ca. 3 Stunden von der Anforderungspräsentation bis zur Auslieferung.
Am Ende würde mit vorgefertigten automatisierten Akzeptanztests geprüft, inwieweit die Anforderungen erfüllt sind. Zwischendurch – vielleicht nach 1,5 bis 2 Stunden – würden noch neue Anforderungen nachgereicht. Und natürlich würde jede Partei ihre Lösung in einem Review vorstellen.
Die Akzeptanztests machen eine Aussage über die Korrektheit des Codes, den ein Ansatz produziert. Die Erfüllung auch der nachgereichte Aufgabe machen eine Aussage über die Fähigkeit, den Code zu verändern, d.h. die Evolvierbarkeit.
Die Größe der Aufgabe ist fast egal, würde ich sagen. Sie muss nicht mal komplett zu schaffen sein. Es reicht, wenn die Zahl der Akzeptanztests nicht zu klein ist und in der Timebox davon eine ganze Reihe schaffbar sind. Dann ließen sich sich Unterschiede im Erfüllungsgrad ablesen. Die nachgereichte Anforderung wäre allerdings eine Pflichtanforderung, die zumindest angegangen werden muss.
Was der Ansatz der anderen Partei ist, ist egal. Sie sollte nur mit C# programmieren. Ob dann streng OOP oder Cowboy Programmierung oder Komponentenorientierung oder Funktionale Programmierung oder sonstwas gemacht wird… alles ist recht.
Hm… einen Aspekt würde ich allerdings noch gern reinbringen: Entwicklung im Team. Wäre also vielleicht gut, wenn auf jeder Seite 3 Leute stünden. Das ist etwas realitätsnäher und ließe größere Aufgaben zu.
Wäre das nicht mal ein Coding Dojo der besonderen Art? Ein “Shoot Out” Dojo oder Contest Dojo. EBC gegen den Rest der Welt :-)
Wer nimmt die Herausforderung an?
33 Kommentare:
Ich würde gerne im EBC Team mitmachen. Mein Terminvorschlag wäre 8./9./10.10 in München. Am 9. und 10. ist in München Barcamp, dadurch lohnt sich die Anfahrt evtl. auch für Auswärtige. Ich kenne einen der Organisatoren des Barcamps ganz gut und könnte mal nachfragen ob dort noch ein Raum frei ist, falls Interesse besteht.
@christine: Freut mich, dass du Lust hast. Aber ich denke, wir sammeln jetzt erstmal Interessierte, bevor wir uns schon für konkrete Teams und Orte entscheiden. Geben wir dem Thema einen Moment...
Geniale Idee... Du hast mich ja damals beim .Net Dojo bei Microsoft und durch Deine diversen Artikel über Softwarezellen und EBC von EBC überzeugt. Ich, obwohl ich kein Professioneller .Net Coder mehr, zähle mich zu der EBC Community.
Ich bin gespannt, ob jemand aus der "klassichen" Ecke, die Herausforderung annimmt. Also halte uns bitte auf dem Laufenden.
Grüße, Alex
PS: Mir persönlich gefällt ja der Begriff SWIC (=Software IC's) besser :-) Du weißt schon wg. Pins, Boards, verdrahten, schwarzer Boxen, etc. Außerdem können IC's so komplex oder einfach sein, wie es der Designer haben will. So wie bei EBC auch :-) Just my opinion!
@AlexS: SWIC? Cool. Taucht bei Google auch irgendwie nicht auf. Noch unverbraucht :-) Schlag den Begriff doch mal in der EBC Diskussionsgruppe bei Google vor: http://groups.google.com/group/event-based-components
Freut mich, dass ich dich "konvertieren" konnte ;-)
Bin auch gespannt, ob sich "aus dem anderen Lager" jemand rührt.
Ein Problem könnte sein, dass das überlegene Team in jeder Methodik (EBC oder Anders) das jeweils andere Team überflügelt.
Für den TimeBoxed Vergleich würde es sich vielleicht anbieten, das online zu machen. Dann können auch verschiedenste Teams aus verschiedenen Städten teilnehmen und die Mitmach-Hürde wäre nicht so groß. Es wäre auch denkbar, das verschiedene EBC-Teams antreten. Teams könnten offline und online kollaborieren. Ausgeschlossen sein sollten Einzelpersonen, da Abstimmung gerade in Teams, ja auch eine Ziel von Architekturmodellen ist.
Hier was ich mir vorstellen könnte:
- Jedes Team muss sich vorher anmelden und sich kurz beschreiben.
- Der Event finden von 18:30 – 21:30 statt.
- Alle Teams müssen Ihre Ergebnisse zu einer Stichzeit abliefern.
- Auch Einzelpersonen sind zugelassen.
- Jede Lösung wird im Anschluss vorgestellt und beschrieben.
- Die Besten 3 Lösungen werden gekürt und es wird begründet, was Sie zu den Besten macht.
- Es gibt keinen Sieger, nur Gewinner - ob Teilnehmer oder Zuschauer.
- Lernen und Entwicklung steht im Vordergrund, nicht Wettbewerb. Kollaboration zwischen Teams, statt Shoot-Out!
Ich hätte Lust so etwas mitzuorganisieren :-) (Vielleicht könnte man das am Abend des OpenSpace in Leipzig machen? Wobei es echt schade ist, dass sich das mit dem prio.walk überschneidet! Auf dem OpenSpace sind gute Leute da, und wenn man das Samstagabend macht, dann könnte man am Sonntag noch darüber sprechen, vergleichen und lernen. )
@robert: Natürlich ist am Ende nicht klar, ob es wirklich am Modellierungsparadigma liegt, wenn eine Gruppe gewinnt. Wäre kein wissenschaftlicher Versuch. Dennoch lassen sich Erkenntnisse gewinnen, denke ich. Und vielleicht ist dann Auftakt zu richtiger Forschung?
Ein online Contest ginge auch, wenn er live stattfindet. Jeder kann daheim sitzen bleiben oder man trifft sich an einem Ort. Jeder wie er mag.
Gut wäre bei einem online Contest, dass es da keine räumlichen Grenzen gäbe. Niemand muss reisen, es passen immer alle, die teilnehmen wollen, in den virtuellen Space ;-) Nur ein Zuschauen gibt es nicht so recht. Aber vielleicht ist das erstmal nicht so schlimm. Es geht ja ums Ergebnis.
Dann muss nur geklärt werden, wie der PO die ganze Zeit ansprechbar ist für Rückfragen. Das könnte per Chat geschehen. Ein Gruppenchat mit allen Teilnehmern?
Wenn alle Teilnehmer nicken, beginnt die Zeit zu laufen. Die Anforderungsklärung würde ich nicht mit messen.
Teilnehmen sollten aber nur gleich große Teams, z.B. 3 Personen. Alle anderen dürfen mitlaufen, aber außer Konkurrenz.
Der Open Space scheidet natürlich aus. Muss ja aber auch nicht sein. Online ist es immer möglich.
Mitorganisieren kann ich auch. Nur Aufgabe aussuchen nicht. Ich will ja als Teilnehmer antreten.
@ralf: Ich habe mal ein Mockup für eine eventuelle Seite dazu gemacht.
http://twitpic.com/2q0geg
Die Rohdaten (Balsamiq) dafür sind hier zu finden: http://github.com/robmi/Architektur-Wettstreit
Also ich würde das gerne konkret (mit)machen. Also eine Domain registrieren, Seite einrichten, Zugänge verteilen (für jeden der mitorganisiert) und Ideen sammeln und aufbereiten?
Als Domain würde ich einfach mal "coding-wettstreit.de" kaufen. Die ist auch noch frei.
Was denkst Du?
@robert: Sehr cool! Das geht in die richtige Richtung, find ich.
Aber "coding-wettstreit" find ich noch nicht so gelungen. Ist mir pers. zuviel Engleutsch ;-) Konsequenter wäre "coding-contest". Aber geht es ums Coding? Ich denke, es geht um mehr. "dev-contest" fänd ich sogar noch passender. oder "dev-team-contest"?
Hm...
@ralf: Wie wäre es mit "entwickler-wettstreit".
Die Namensvorschläge bisher (Domains sind für alle noch frei):
- coding-contest
- dev-contest
- entwickler-wettstreit
- dev-team-contest
Verworfen:
- coding-wettstreit (denglish)
@robert: entwickler-wettstreit find ich nicht schlecht. Klingt ein bisschen nach Ritterspielen und Minnesang ;-)
Aber warten wir mal auf andere Stimmen...
Klingt sehr sportlich und erinnert mich auch ein wenig an die Demo-Coders-Szene. ;-)
"Sparring-Kumites" (http://www.altnetberlin.de/Termine/coding-dojo) als mögliche Coding Dojo Variante klingt auch sehr ähnlich, wenn auch eher die Erkenntnis und nicht der Wettstreit im Vordergrund steht. Was mich gleich zu der Frage führt - Was soll den das/Dein Ziel einer solchen Veranstaltung sein? Mein Karate ist besser als dein Karate? Oder eher - Ahh so geht das auch gut/besser?
@Mike: Naja, am Ende geht es immer um Erkenntnis.
Aber die Nähe zum Coding Dojo würde ich hier aus der Erfahrung mit der Diskussion, was denn ein Coding Dojo sei, nicht suchen. Kumite, Bunkai, Sparring... ne, ne, nicht die Dojo Hüter wieder wecken ;-)
Also warum nicht mal Deutsch: Entwicklerwettstreit. Denn ein sportlicher Wettstreit soll es sein. Es soll sich auch eine Seite als besser profilieren. Die wichtige Frage dann aber: Warum ist sie besser.
Die Entscheidungskriterien aus meiner Sicht sollten zunächst solche sein, die einen Hinweis darauf geben, ob der Code höhere innere Qualität hat. Ich will sehen, wer Evolvierbarkeit und Korrektheit hinbekommt.
OK, verstanden als Wettstreit/bewerb der Programmier- und Entwicklungskünste. Flexibilität, Evolvierbarkeit, Eleganz hat ja IMHO auch etwas künstlerisches.
Korrektheit sollte bei beiden Seiten ja selbstverständlich sein.
Psst - Damit bekommen, zumindest die Experten-, Dojos auch gleich noch einen weiteren anderen Sinn. Naja, Du hast Recht - Distanz zu Coding Dojos ist sicher nicht schlecht und gleich auch ein bisschen konspirativer ;-).
Ich finde Deine Herausforderung ja ganz nett, aber leider konnte ich den Stein des Anstoßes oder potentielle Mitbewerber mit anderer Strategie noch nicht finden. Was ist Krank? EBC als Konzept, Methode, Architekturmuster, die Implementierung - mir fehlt hier der komplette Kontext. Worum ging es als Ziel noch - Warum ist diese Lösung besser als die andere? Wer ist die Jury - die Community?
@Mike: Also für mich ginge es darum möglichst viele Lösungswege für die gleiche Aufgabe zu sehen und daran zu lernen. Erkenntnisse würde ich mir auch im Detail wünschen: "Was sind gute Namen?", "Wie sieht die Projektstruktur aus?", "Wie wird getestet (TDD/BDD),“, „Wie sind die unterschiedlichen Stile?". Auf einer übergeordneten Ebene würde ich mir wünschen etwas über Architektur und Prozesse zu lernen. Was ist schnell in der Umsetzung, was ist verständlich...
Ich denke ein solcher Vergleich wäre auch ein wunderbarer Weg, Gesprächen und Dialog Futter zu geben. (Die Clean-Code und ALT.NET Mailingliste sind still geworden…).
@Ralf, @Mike: Ich denke der Trainingseffekt sollte in den Vordergrund gestellt werden und das gemeinsame Erlebnis. Der Sieger sollten die Teilnehmer sein (Das klingt auch schön platt.)! Lob, Ehre und Anerkennung für die herausstechensten Lösungen gehören als Anreiz sicherlich dazu, aber das sollte nicht die treibende Kraft sein. In die Dojo-Ecke würde ich das auch nicht packen, da Geschwindigkeit eine wesentliche Komponente sein sollte. Ich würde vorschlagen die Aufgabe so anzulegen, das die Zeit knapp ist.
@Ralf: Das Bewertungskriterium "Evolvierbarkeit" find ich sehr gut, auch wenn es natürlich unscharf ist. Wie bewertet man Evolvierbarkeit? Sonst würde ich allgemein diese Bewertung nehmen:
- Vollständigkeit der Lösung
- Lesbarkeit
- Projektstruktur
- Anpassbarkeit (Test-coverage, Erlernbarkeit für neue Entwickler)
- Clean-Code (?)
@MikeBild: Jury sollte aus 3, 4 Leuten bestehen, die halt nicht teilnehmen und vorher bestimmt werden.
@All: Ich finde es sollte nicht EBC vs. XY sein. Sondern etwas wo auch jemand teilnehmen kann, der mit EBCs nichts am Hut. Nicht dafür, nicht dagegen ist. (Als Teilnehmer würde ich mich auch nicht an EBCs versuchen sondern einen Ansatz wählen den ich gut kann! Aus den Ergebnissen könnte ich dann was über EBC lernen - muss aber auch nicht sein.)
@Robert Finde ich nicht, wir brauchen Fokus, eine Disziplin, im Wettstreit.
Hoi Ralf,
da es gegebenenfalls schwierig sein wird, hier jemanden von der "Gegenseite" zu finden, melde ich mich mal ;-).
Nicht, weil ich EBCs schlecht fände oder mir die Idee nicht gefiele - sondern weil es ja gegebenenfalls auch mal Spaß macht, den Advocatus Diaboli zu spielen ...
Soll heißen: Wider meine Überzeugung würde ich mal "klassisch" arbeiten und gucken, ob ich nicht ohne EBCs schneller, besser oder was auch immer wäre ;-).
Viele Grüße,
Golo
Denn Wettstreit-Charakter würd ich drin lassen. Ein freundschaftlicher Wettstreit natürlich. Denn Wettstreit bringt positive Emotionalität.
"Entwicklerwettstreit" wäre eine Variante. Oder "dev matrix battle"? :-)
Positioniert sehe ich das Ganze aufbauend auf Coding Dojos. Dojos sind geschützte Orte des Übens. Bei der "dev matrix battle" geht es aber nicht mehr ums Übens, sondern ums anwenden.
So können sich Dojos und Battle befruchten: Im Dojo lernen fürs Battling. Aus der Battle mitnehmen, woran man im Dojo noch feilen sollte.
So war´s ja auch bei den Japanern: Im Dojo Yaido oder Karate machen - dann in den Kampf und damit gewinnen :-)
Wer in der Battle gegeneinander antritt, ist egal. "The EBC Warriors" vs "Monsters of OOP"? Oder "C# Cats" vs "IronRuby Tigers"?
Am Ende gehts darum, dass in mehreren Kategorien Punkte gesammelt werden: Funktionalität, Evolvierbarkeit, Korrektheit.
Funktionalität und Korrektheit werden geprüft durch vorgegebene Akzeptanztests.
Korrektheit wird darüber hinaus noch durch Testcoverage geprüft.
Evolvierbarkeit wird geprüft durch ausgewählte Metriken (z.B. CC) und Akzeptanztests. Denn es werden manche Anforderungen nachgereicht.
Es gilt also: viele Features in der Timebox fehlerfrei mit hoher Testcoverage implementieren.
Einzige Anforderung an die Umsetzung: Sie muss das Interface bedienen, auf dem die Akzeptanztests aufsetzen. Das könnte ein Dateninterface sein (es werden Dateien eingelesen und Ergebnisdateien produziert, die gegen Goldmaster verglichen werden). Oder das könnte ein API/Interface sein, der von Unit Tests aufgerufen wird.
Ob dann die Implementation selbst automatisierte Tests einsetzt, ist egal. Es geht nur ums Ergebnis. Insofern muss auch kein Review gemacht werden, um den Sieger zu küren.
Der Review ist natürlich trotzdem nett, um vom Sieger zu lernen. Aber ein Kunde interessiert sich auch nicht für den Code, sondern nur für das Ergebnis. Und auf dem Niveau möchte ich die Battle halten: relevant für die Praxis.
Denn das Argument aller Gegner des Neuen ist immer: was bringt mir das für die Praxis? In der zählt aber nur, was ich auf die Straße bringe.
Wenn CCD und EBC es nicht schaffen, besser als "home grown OOP" zu sein... dann können wir damit aufhören (oder müssen eben nachbessern).
Ich bin leider noch zu neu im EBC Thema, aber schon (fast) überzeugt.
Ich wäre deshalb keine Vertärkung für das EBC Team, drücke Euch allen die Daumen und bin sicher das EBC vorne liegen wird...
Sorry ...
Ich würde mich, aus offensichtlichem Mangel BASHING ;-), auch für die Gegenseite "Klassik" anmelden. Funktioniert ja eh besser. :-)
Hi,
ich bin auch schon vom EBC-Konzept überzeugt. Allerdings habe ich überhaupt keine Erfahrung damit, außer dass es sich super in MVP-Designs einsetzen lässt. Allerdings habe ich noch nie eine größere Anwendung damit aufgesetzt.
Aus Mangel an Erfahrung in EBC würde ich mich auch für die klassische Seite melden.
Das ganze allerdings nur, wenn der Termin nicht gerade mitten in meinem Urlaub liegt und wir das irgendwie online hinbekommen.
Gruß Basti
(Ich muss mir hier mal noch ein Konto besorgen)
Hallo,
die Idee klingt sehr interessant. Je nachdem wann und wo das stattfindet würde ich auch gerne teilnehmen. Meine EBC Erfahrungen beschränken sich aber auf das CCD Praktikum und ein paar kleinere Hobby-Projekte :) Sonst eben die "klassische Seite" ...
Könnte man das nicht während der PRIO machen, zumindest wären dort für eine zentrale Offline-Variante genügend Leute & Publikum :) Aber vermutlich auch wenig Zeit ...
Christoph
Ja Servus mitananda,
bin auch nicht fit in ebc aber mich wuerden Auch die Erkenntnisse daraus interessieren. Also mach ich so wie ich das am besten kann. Also wenn's wo in muenchen und Umgebung stattfindet oder ontheline, dann sagt bitte Bescheid.
AetRalf: Vui Griass aus muenchen...
Servus,
Manuel
Hallo,
die Idee finde ich sehr gut, und EBC ebenso. Arbeite mich aber gerade erst ein.
Den Online-Ansatz für den Wettstreit finde ich daher sehr gut. Das könnte ein Dauerbrenner werden.
Damit auch die "Zuschauer" auf ihre Kosten kommen, könnte ich mir vorstellen, das der Event auch im Teamspeak stattfindet. Da könnten Interessierte dann auch in die Team-Channels reinhören, und zum Ende des Wettbewerbs könnten die Teams dann ihre Lösungen auch erläutern. Das wäre dann eLearning live :-))
Grüße an die Runde
Ralf
Wann und wo findet das Ganze denn nun statt?
Wenn sich denn zwei klare Parteien gefunden hätten, könnten wir weiter planen. Derzeit sehe ich die aber leider noch nicht :-(
Also: Wo sind die zwei Teams, die ??? mit einem EBC Ansatz sportlich vergleichen? Ein halbes EBC-Team sind Stefan Lieser und ich; da darf noch ein EBC-Aficionado dazu kommen - aber zur Not machen wir es auch allein :-)
Welches 3er-Team steht auf der anderen Seite?
Ah, ok, es ging für mich aus den bisherigen Postings nicht so klar hervor, dass zunächst die Teams zusammengestellt werden. Ich bin davon ausgegangen das zunächst ein Organisator/Location/etc. gesucht wird. Wie kann man sich denn für ein Team anmelden/bewerben?
@Anonym: Einfach hier dein Interesse bekunden ;-)
Das haben einige andere Leute hier auch getan. Es scheint aber nicht als Anmeldung gewertet worden zu sein.
herbivores Kritik an EBC, die laut Blogbeitrag offensichtlich der Anlass für den Wettstreit war, bezog sich konkret nur auf die Veränderungen, die mit EBC 2.0 aufgekommen sind, namentlich dem Fokussieren auf Aktionen. Das ist leider schon an verschiedene Stellen unter den Tisch gefallen. Auch der verwendete Begriff, der den Stein des Anstosses geliefert hat, fiel erst als Befreiungsschlag, nachdem aus meiner Sicht sehr unfein versucht wurde, herbivore in die Ecke eines "unreflektierten Dogmatikers" zu stellen. Bis dahin war seine Kritik ausgesprochen moderat, wenn auch aus bestimmten Gründen nur sehr oberflächlich formuliert.
Bei aller Euphorie für den Wettstrett halte ich diesen aus mehreren Gründen für nicht zielführend:
Zum ersten haben die Qualifikation, die Fähigkeiten und die Übung der Teams einen weit größeren Einfluss auf das Ergebnis als die eingesetzte Technik (EBC 2.0 oder OOP). Insbesondere, wenn du, Ralf, als Teilnehmer antrittst, der du durch solche (schätzenswerten!) Aktionen wie das Kaffeehaus-Consulting drauf trainiert bist, dich innerhalb kürzester Zeit in die verschiedensten Aufgabenstellungen einzudenken und sofort Modelle und Lösungen dazu auszuspucken. Es herrscht m.E. schon zu Beginn ein Ungleichgewicht zwischen den Teilnehmern bzw. den teilnehmenden Gruppen.
Zum zweiten kann man aus den Ergebnissen von einer so kleinen Aufgabe (3 Stunden) nicht auf die in der Praxis vorkommenden Fälle (mehre Monate bis mehrere Jahre), also auf große Projekte schließen. Kleine Aufgaben kann man ohne weiteres mit einem imperativ-/prozedural-artigen Ansatz (sprich ein Ansatz, der die Aktionen und nicht die Daten in den Vordergrund stellt) lösen bzw. kann der imperativ-/prozedural-artige Ansatz gerade bei kleinen Aufgaben seine Vorteile ausspielen. Nicht umsonst hat die Programmierung in Hochsprachen so begonnen und ist erst dann zur Objektorientierung gewechselt, als der Code immer größeren Umfang angenommen hat.
Zum dritten hat die konkrete Aufgabe sicher ebenfalls einen erheblichen Einfluss auf den Ausgang des Wettstreits. Schon die bisher vorgeschlagene Beispiele sind sehr auf EVA ausgerichtet und spielen dem imperativ-/prozedural-artigen Ansatz von EBC 2.0 in die Karten. Aus meiner Sicht sind das aber gerade nicht die Beispiele aus der Praxis. Eine typische Aufgabe, die im anderen Extrem OOP sehr in die Karten spielen würde, wäre eine Verwaltungsaufgabe, bei der die Daten und einfache Datenänderungen im Vordergrund stehen, z.B. eine Benutzerverwaltung inkl. Rechtevergabe.
@gfoidl: gerade eine ähnliche Problem-Domäne wie deine haben wir exemplarisch genommen um eine "Vorstufe" von EBC ins Team zu tragen - es hat sich bestens gezeigt, dass EBCs ein Schritt in eine Richtung sind, die sich einfach besser anfühlt ...
Aber Recht geben muss ich dir, dass es schwierig wird ein adäquates Team gegen Ralf und Stefan aufzustellen ;-)) ...
Beste Grüße, Marko
Über die Unterscheidung zwischen EBC 1.0 und EBC 2.0 bin ich auch gestolpert, aber nach meinem Test Projekt (siehe EBC Group bei Google), bin ich der Meinung, dass sich beides keinesfalls ausschließt, sondern eher zusammen gehört.
Ich werde daher nur noch von EBC sprechen und beides anwenden. Die Akteure und Aktionen gehören halt zusammen.
Was den Wettstreit angeht, war ich auch erst interessiert, aber ich denke dass der Zeitdruck einer solchen Aktion kontraproduktiv ist. Ich selber brauche immer etwas Zeit um wirklich vernünftige Namen zu finden. Und auch über einen Entwurf denke ich lieber zweimal nach.
Ideen müssen einfach reifen...
Dennoch vielen Dank für diese Idee!
Viele Grüße,
Christof
Kommentar veröffentlichen