Motivation bei Privatprojekten (Split aus Diamond of Death)
-
hustbaer schrieb:
Ich glaube nicht dass du *wirklich gut* Java und/oder C# kannst. Zumindest nicht gut genug, um beurteilen zu können, was von Java oder C# "zu halten ist"
Ich habe angefangen, die STL in Java zu implementieren. (Zumindest das Design habe ich versucht, möglichst ähnlich zu halten.)
Ich kann dir Code liefern, wenn du darauf bestehst, ich kann diese Sprachen gut genug. (Wobei ich Java besser kann.)Es würde meinen Stolz verletzen, den Bot nicht in C++ zu schreiben.
-
In Java wäre es viel zu einfach - da fehlt die Herausforderung.
-
antijava schrieb:
In Java wäre es viel zu einfach - da fehlt die Herausforderung.
Einer ders kapiert hat - hurray!
-
314159265358979 schrieb:
hustbaer schrieb:
Ich glaube nicht dass du *wirklich gut* Java und/oder C# kannst. Zumindest nicht gut genug, um beurteilen zu können, was von Java oder C# "zu halten ist"
Ich habe angefangen, die STL in Java zu implementieren. (Zumindest das Design habe ich versucht, möglichst ähnlich zu halten.)
Das sagt mir eigentlich nur, dass du Java als "way of doing it" einfach nicht verstanden hast
(Oder nicht akzeptiert, nur die Unterscheidung ist irrelevant, wenn es darum geht ob du beurteilen kannst was die Sprache "taugt")Es würde meinen Stolz verletzen, den Bot nicht in C++ zu schreiben.
Dann mach mal. Du hast das Thema ja schon ne gute Zeit lang ins Auge gefasst. In der Zeit müsstest du das längst fertig haben. Ist ja kein extrem grosses Projekt.
Halte dich an das Motto "just do it".
Überleg nicht tagelang rum wie du dieses oder jenes designen könntest, was du hier oder da noch feilen könntest/hübscher machen etc.
Setzt dich einfach hin, überleg dir ein grobes Konzept wie die einzelnen Teile zusammenspielen sollen ("Design"), und dann implementier es. Geh' beim Erstellen des Konzepts/Designs nicht zu sehr in die Tiefe, sieh lieber zu dass du die Breite vollständig abdeckst.
Und wie gesagt: implementier es.
Auch dabei wieder: nicht zu sehr auf Perfektion achten.Und zwar aus mehreren Gründen: erstmal fehlt dir für "Perfektion" einfach die Erfahrung. Und dann, selbst mit 10+ Jahren Erfahrung bekommt man es auch nie "perfekt" hin. Alle möglichen Lösungen haben Vor- und Nachteile, diese "perfekt" gegeneinander abzuwägen und dann den "perfekten" Kompromiss zu finden, ist einfach unmöglich.
Gut genug ist gut genug
Und beim nächsten mal hast du mehr Erfahrung, und machst weniger Fehler. Oder zumindest andere Fehler.Aber eins ist sicher: wenn du nie was fertig machst, dann kannst du auch kaum wertvolle Erfahrung sammeln. Oder anders gesagt: die Grösse der Projekte die du umsetzen kannst, ohne dass am Ende ein "unwartbares Monster" rauskommt, wird vermutlich nicht wachsen.
Noch eins:
Ein Projekt fängt damit an, dass man sich genau überlegt was es können/tun soll. Und vor allem: es niederschreibt.
-
Sagen wirs mal so, ich finde die Java Collections einfach zum kotzen. Deshalb habe ich mir eine STL geschnitzt, um das ganze etwas erträglicher zu machen.
@Topic
Das wären meine nächsten Fragen gewesen. Was hält man schriftlich fest, wie plant man ein Design richtig?
-
Was hält man fest...
Naja, erstmal die Anforderungen halt.
Die funktionellen Anforderungen, also was das Ding können soll.
Und die nicht-funktionellen Anforderungen, also z.B. in welchem Environment es laufen soll (OS, eventuelle andere Systeme die eingebunden/genutzt werden müssen), ob eine bestimmte Sprache vorgeschrieben ist, welche Performance man brauch (X concurrent Connections to Y Peers, Z Messages/Second - was auch immer) etc.
Eine Sache die sich, besonders für die funktionellen Anforderungen, gut eignet, sind User-Stories und Use-Cases. In deinem Fall hättest du vermutlich (auch) User-Stories und Use-Cases, wo der "User" das Bot-Plugin ist das "in" deinem Bot-Server laufen soll.
Wobei du u.U. eine Stufe höher ansetzen solltest als "ich will nen plugin fähigen IRC Bot".
z.B.: warum glaubst du einen plugin fähigen IRC Bot zu wollen? Was willst du damit erreichen?
Wäre nicht vielleicht ein "IRC-Bot-Framework" ausreichend, mit dessen Hilfe ich mit wenig Aufwand einen eigenen IRC-Bot schreiben kann?
Das würde einiges vereinfachen.
Einerseits die Schnittstelle. Dann bekommst du perfekte Isolation der verschiedenen Bots quasi geschenkt, da alle Bots in eigenen Prozessen laufen. Mehrere Prozesse sind lange nicht so "teuer" wie du vielleicht denkst. (Guck dir bloss mal ältere Apache-httpd Versionen an, die haben einfach für jeden Request den ganzen Prozess kopiert (fork()).)
-
Okay, erst mal vielen Dank
Warum Plugins und kein Framework?
- Ich brauche nur einen Bot
- Mein IRC Netzwerk (Quakenet) lässt nur 5 Connections/IP zu
- Ich möchte Module laden können ohne NeustartAchja: Schreibt man die Anforderungen auf Englisch oder auf Deutsch?
-
314159265358979 schrieb:
Achja: Schreibt man die Anforderungen auf Englisch oder auf Deutsch?
Am besten auf japanisch.
-
Mandarin
-
Was für ein Thread...
PI, wieso machst du nicht ein Thread auf mit dem Titel: "IRC BOT (Plugins)".Die ersten Posts zu dem eigentlichen Thema waren noch recht interessant, weil es mir auch manchmal so geht. Aber dann ist der Thread total abgeschweift nach "Welche Sprache, Welche IPC-Methode, etc.".
Am besten bennent ein Moderator bitte den Thread um. Das ist Irreführung :p
-
Man könnte ja den Split nochmal splitten und den Split-Split ins C++-Forum schieben. Mir solls recht sein.
-
Was gehört zur Planung eines Designs dazu? Wie genau muss so eine Planung aussehen?
- Sollen nur die Klassen geplant werden in ihrer Funktionsweise?
- Soll das Interface von Klassen, möglicherweise auch Funktions-Signaturen mit geplant werden mit Beschreibung der einzelnen Funktionen?
- Sollen private Member (sowohl Variablen, als auch Funktionen) geplant werden?
-
Oh Mann...
Du überspringst schon wieder Schritte.1: Anforderungen definieren. Was soll das Ding können?
Sich davor über's Design Gedanken zu machen führt zu nichts Gutem!
-
- Verbindung nur zu einem Server, multi-Server Support nicht erforderlich
- Multi-Channel support
- Config Datei für Daten wie Server, Nickname, Username, Whois-Text, ...
- Soll unter Ubuntu 11.04 (Server) und Mac OS X 10.6 (Lappi) lauffähig sein
- IPC über Shared Memory mit Plugins
- Events für Plugins für jede Art an "Dingen", die im IRC halt so auftreten können: MOTD, Kick, Ban, Op, Voice, Topic-change, Chanmode-change, Query, Normale Channel Nachricht, Ping, CTCP, aber auch Fehler, wie: Nickname schon vorhanden, keine Rechte, G-Line, Verbindungsfehler, etc.
- Automatisches Laden aller Plugins aus einem plugins/ Unterordner bei Start
- Nachladen/Deaktivieren/Neuladen von Plugins über den Bot
- Simples Logging in eine Datei, die bei jedem Start einfach überschrieben wird, hier sollen einfach alle Nachrichten rein, sowie die, die der Bot gesendet hat, und zwar Server Nachrichten beginnend mit "S: ", Bot-Nachrichten beginnend mit "C: "
- Steuerung des Bots über die Konsole: Connect, Disconnect, Plugin-Management, ...Ist das richtig so?
-
Pfuh, jain.
Du vermischt schon wieder das "wie" mit dem "was". Um das "wie" geht's beim Anforderungen definieren schonmal (meistens) nicht. "IPC über Shared Memory" ist "wie", nicht "was". Was ist das "was" dazu?Aber egal.
Jetzt formulier das ganze genauer aus.
Stichwort User Stories und Use Cases.
-
Ich habe mir das hier ergoogelt:
http://de.wikipedia.org/wiki/User_Story
http://de.wikipedia.org/wiki/AnwendungsfallAllerdings fange ich damit nicht wirklich was an...
-
Such nach englischen Seiten, da findet man mehr.
Such nach "use case examples".Zwei nicht ganz unbrauchbare Beispiele:
http://www.math-cs.gordon.edu/courses/cs211/ATMExample/UseCases.html
http://www.acs.ilstu.edu/faculty/bllim/oo/usecase.htm
-
Wenn ich das also richtig verstanden habe, ist ein Use Case eine Beschreibung eines einzelnen Vorgangs, wie "Bot wird gestartet", "eine Nachricht vom Server trifft ein", oder "Plugin will Antwort senden". Dabei wird allerdings nur beschrieben, was getan wird (aus Sicht des Benutzers des Bots), aber nicht wie.
Was wären denn die "Use Cases" bei meinem Bot? Mir würden hier folgendes einfallen:
- Startup (Besteht aus Connect, Plugin-Load)
- Nachricht vom Server trifft ein (Besteht aus Logging, Informieren des Plugins, und Verarbeitung durch Plugin)
- Antwort eines Plugins (Bot informieren, Logging, Senden)
- Shutdown (Plugins informieren, auf Beendigung der Plugins warten, "hängende" Plugins terminieren, Verbindung beenden)
-
Wenn ich das also richtig verstanden habe, ist ein Use Case eine Beschreibung eines einzelnen Vorgangs, wie "Bot wird gestartet", "eine Nachricht vom Server trifft ein", oder "Plugin will Antwort senden". Dabei wird allerdings nur beschrieben, was getan wird (aus Sicht des Benutzers des Bots), aber nicht wie.
Ich vermute dass du es halbwegs richtig verstanden hast.
Das "wie" wird schon beschrieben, aber nur das "wie" aus Sicht des Benutzers. Das ist auch wichtig, genau darum geht es in einem Use-Case.Eine User-Story wäre "Als Bot-Besitzer möchte ich über die Konsole Plugins nachladen können".
Der Use Case würde dann detailiert beschreiben wie der User das machst, und wie das System darauf reagiert.Beide sprechen aber nicht über die Implementierung.
Mir würden hier folgendes einfallen: (...)
Ja das könnte hinkommen. Das sind aber erst "Titel" von User-Stories/Use-Cases, jetzt musst du sie noch ausformulieren.
Und...
- Nachladen/Deaktivieren/Neuladen von Plugins über den Bot
- Steuerung des Bots über die Konsole: Connect, Disconnect, Plugin-Management, ...Beim 2. Punkt wirst du vermutlich sogar mehrere Use-Cases haben.
Jede Aktion die jmd. über die Konsole durchführen will ist ein Use-Case.
Und für "..." ist in der Planung kein Platz, "..." gibt's nicht.
-
===============================================================================================================================================================================
StartupUser Story: Als Bot-Besitzer möchte ich, dass mir der Bot eine neue Konfigurations-Datei bei Start anlegt, wenn keine existiert.
Use Case: Config bei Start
Voraussetzung:
- Die Konfigurationsdatei "bot.conf" existiert nicht.Beschreibung:
- Der Bot legt eine neue Config mit dem Dateinamen "bot.conf" an. (Use Case: Config-Erstellung)Ausnahmen:
- Die Datei existert bereits. Nichts passiert.-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
User Story: Als Besitzer des Bots möchte ich, dass der Bot bei Start eine neue Log-Datei anlegt.
Use Case: Log-Start
Voraussetzungen:
- Die Log-Datei existert noch nicht.Beschreibung:
- Der Bot versucht, eine neue Datei mit dem Namen "bot.log" anzulegen.Ausnahmen:
- Die Datei existert bereits. Die alte Datei wird überschrieben.
- Die Datei konnte nicht erstellt werden. Der User wird mit der Meldung "Couldn't create logfile." informiert. Der Bot fährt sich herunter.
(Use Case: User-Information, Shutdown)-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
User Story: Als User möchte ich, dass sich der Bot beim Start automatisch mit dem Server verbindet.
Use Case: Auto-Connect
Voraussetzungen:
- Ein Host + Port wurde in der Config angegeben.Beschreibung:
- Der User hat einen Host und einen Port in der Konfigurationsdatei angegeben.
- Der Bot verbindet sich mit dem Host über den angegebenen Port. (Use Case: Connect)Ausnahmen:
- Kein Host oder Port wurde angegeben. Nichts passiert.
- Nur der Host wurde angegeben. Der Bot versucht, sich über den Port 6667 (default IRC Port) mit dem Host zu verbinden. (Use Case: Connect)
- Nur der Port wurde angegeben. Der Bot informiert den User mit der Nachricht "Host missing for port <port> in config file." und schreibt selbige Nachricht in die Logdatei.
(Use Case: User-Information, Logging)
- Die angegebene Portnummer ist ungültig. Der User wird darauf mit der Fehlermeldung "Invalid port number <port> in config file." hingewiesen. (Use Case: User-Information)
Die Meldung wird auch in die Log-Datei geschrieben. (Use Case: Logging)-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
User Story: Als Bot-Benutzer möchte ich, dass der Bot alle Plugins beim Start lädt.
Use Case: Auto-Plugin-Load
Voraussetzungen:
- Das Plugin Verzeichnis "plugins/" existiert.
- Die Plugins im Verzeichnis haben die Dateiendung ".plg".Beschreibung:
- Der Bot lädt alle Plugins mit der Dateiendung ".plg" aus dem "plugins/" Unterordner im Bot-Verzeichnis.Ausnahmen:
- Das Verzeichnis existiert nicht. Der Bot erstellt ein leeres "plugins/" Verzeichnis. (Use Case: Plugin-Ordner erstellen)
- Das Laden eines Plugins ist fehlgeschlagen. Der Bot informiert den User über den Fehlschlag mit der Nachricht "Couldn't load plugin <plugin-name>." und schreibt selbige
Nachricht in die Logdatei. (Use Case: User-Information, Logging)===============================================================================================================================================================================
===============================================================================================================================================================================
Kommunikation mit dem ServerUser Story: Wenn eine Nachricht vom Server kommt, möchte ich, dass der Bot die Nachricht loggt und die Plugins auf die Nachricht reagieren können.
Use Case: Nachricht von Server
Voraussetzungen:
- Plugins wurden geladen
- Die Nachricht entspricht dem IRC Protokoll RFC 1459Beschreibung:
- Eine Nachricht vom Server trifft ein.
- Der Bot schreibt die Nachricht in die Log-Datei und hängt ein "S: " - Präfix an. (Use Case: Logging)
- Der Bot bringt die Nachricht in eine für Plugins besser verarbeitbare Form.
- Der Bot informiert die Plugins, damit sie die Nachricht verarbeiten können.Ausnahmen:
- Keine Plugins wurden geladen. Nichts passiert.
- Die Nachricht entspricht nicht RFC 1459. Der Bot verwirft die Nachricht und schreibt in den Log, dass eine ungültige Nachricht ankam: "Invalid message from server: '<msg>'"
(Use Case: Logging) Der User wird davor mit der selben Nachricht über den Fehler informiert. (Use Case: User-Information)-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
User Story: Wenn ein Plugin eine Nachricht zum Server sendet will, soll die Nachricht vom Bot geloggt werden, bevor sie gesendet wird.
Use Case: Nachricht von Plugin
Voraussetzungen: Keine
Beschreibung:
- Ein Plugins informiert den Bot, dass es eine Nachricht senden möchte.
- Der Bot setzt eine laut RFC 1459 gültige Nachricht zusammen.
- Der Bot schreibt die Nachricht in die Log Datei und hängt ein "C: " - Präfix an. (Use Case: Logging)
- Der Bot sendet die Nachricht zum Server.Ausnahmen:
- Die Nachricht ist ungültig. Der Bot Verwirft die Nachricht und schreibt in den Log, dass eine ungültige Nachricht ankam: "Invalid message from plugin <plugin-name>: '<msg>'"
(Use Case: Logging) Der User wird davor mit der selben Nachricht über den Fehler informiert. (Use Case: User-Information)===============================================================================================================================================================================
===============================================================================================================================================================================
ShutdownUser Story: Als Bot-Besitzer möchte ich, dass der Bot versucht, alle Plugins ordnungsgemäß herunterzufahren.
Use Case: Plugin-Shutdown
Voraussetzungen:
- Eine Wartezeit für Plugins, die sich herunterfahren, wurde in der Konfigurationsdatei eingestellt.Beschreibung:
- Der Bot informiert alle Plugins über den bevorstehenden Shutdown.
- Der User wird durch die Nachricht "Shutting down plugins..." informiert, selbige Nachricht wird in den Log
geschrieben. (Use Case: User-Information, Logging)
- Der Bot wartet die in der Config eingestellte Zeit, um den Plugins etwas Zeit zu geben, sich zu beenden.
- Alle Plugins, die sich nicht beendet haben, werden ohne weitere Kommunikation terminiert.
- Der User wird informiert, wenn Plugins terminiert werden mussten, und zwar mit der Nachricht "The following plugins had to be terminated: <plugin-list>".
(Use Case: User-Information) Die selbe Nachricht wird in die Logdatei eingetragen. (Use Case: Logging)
- Der Bot schreibt in den Log (Use Case: Logging) und informiert den User (Use Case: User-Information) mit der Nachricht: "Plugin shutdown complete."Ausnahmen:
- Keine Plugins wurden geladen. Nichts passiert.
- In der Config wurde keine Wartezeit eingestellt. Der Bot wartet 500 ms auf Beendigung.
- Das Logging schlägt fehl. Der Bot ignoriert den Fehler und geht weiter vor wie geplant.-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
User Story: Als User erwarte ich, dass der Bot bei Beendigung die Verbindung beendet.
Use Case: Bot-Shutdown
Voraussetzung: Keine
Beschreibung:
- Der Bot informiert den User mit der Nachricht "Shutting down Bot..." (Use Case: User-Information) und schreibt selbiges in den Log. (Use Case: Logging)
- Der Bot schreibt in den Log (Use Case: Logging) und informiert den User (Use Case: User-Information), mit der Meldung "Closing connection...".
- Der Bot schließt die Verbindung zum Server.
- Der Bot informiert den User und schreibt in den Log "Connection closed." (Use Case: User-Information, Logging)
- Der Bot schreibt in den Log und informiert den User mit der Nachricht "Bot shutdown complete." (Use Case: User-Information, Logging)
- Das Programm endet.Ausnahmen:
- Das Logging schlägt fehl. Der Bot ignoriert den Fehler und geht weiter vor wie geplant.===============================================================================================================================================================================
===============================================================================================================================================================================
KonsoleUser Story: Als Bot-Besitzer möchte ich, dass ich den Bot über die Konsole zu einem Server verbinden lassen kann.
Use Case: Console-Connect
Voraussetzungen:
- Der User hat in der Konsole einen gültigen Verbindungsbefehl eingegeben. ("connect <host>[:<port>]")
- Der Bot ist mit keinem Server verbunden.Beschreibung:
- Der User gibt in der Konsole "connect <host>[:<port>]" ein.
- Der Server verbindet sich über den Port <port> mit dem Host <host>. (Use Case: Connect)
- Die Plugins werden aktiviert.Ausnahmen:
- Der User hat weder Host, noch Port angegeben. Der User wird aufgefordert, eine gültige Eingabe zu machen, mit der Nachricht:
"Invalid parameters. Syntax: connect <host>[:<port>]"
- Der Bot ist bereits mit einem Server verbunden. Der User wird darüber informiert mit der Nachricht "Already connected to <host>:<port>.".
- Der User hat keinen Host angegeben. Der User wird mit der Fehlermeldung "Host missing for port <port>" darauf hingewiesen.
- Der User hat keinen Port angegeben. Der Bot versucht, sich auf Port 6667 (default IRC Port) mit dem Server zu verbinden. (Use Case: Connect)
- Der User hat keine gültige Portnummer angegeben. Er wird darauf mit der Fehlermeldung "Invalid port number." hingewiesen.-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
User Story: Als Besitzer des Bots möchte ich, dass der Bot auf Befehl die Verbindung zum Server beendet.
Use Case: Console-Disconnect
Voraussetzungen:
- Der User hat "disconnect" eingegeben.
- Der Bot ist mit einem Server verbunden.Beschreibung:
- Der User gibt "disconnect" in der Konsole ein.
- Der Bot informiert Plugins über den bevorstehenden Disconnect.
- Der Bot wartet die in der Config eingestellte Zeit, um den Plugins Zeit zu geben, Nachrichten zum Server zu senden.
- Der Bot schließt die Verbindung zum Server. (Use Case: Disconnect)
- Alle Plugins werden deaktiviert. (Use Case: Plugin-Shutdown)Ausnahmen:
- Der Bot ist mit keinem Server verbunden. Der User wird auf den Fehler mit der Nachricht "Not connected." informiert.
- In der Config ist keine Zeit eingestellt. Der Bot wartet 500 ms auf Beendigung.===============================================================================================================================================================================
So, das wars fürs erste, meine Motivation sinkt wieder. Vielleicht mache ich später noch weiter, ansonsten morgen.
