Motivation bei Privatprojekten (Split aus Diamond of Death)
-
314159265358979 schrieb:
Ist bei mir eigentlich nur Motivationsmangel. Wie haltet ihr immer so lange durch bei euren Projekten?
Viele der Leute hier bekommen Geld dafür
.
-
SeppJ schrieb:
314159265358979 schrieb:
Ist bei mir eigentlich nur Motivationsmangel. Wie haltet ihr immer so lange durch bei euren Projekten?
Viele der Leute hier bekommen Geld dafür
.Ich meine da eigentlich private Projekte
-
314159265358979 schrieb:
SeppJ schrieb:
314159265358979 schrieb:
Ist bei mir eigentlich nur Motivationsmangel. Wie haltet ihr immer so lange durch bei euren Projekten?
Viele der Leute hier bekommen Geld dafür
.Ich meine da eigentlich private Projekte
Na, da musst du halt etwas machen, was dir Spass macht. Dann geht das ganz gut.
-
drakon schrieb:
314159265358979 schrieb:
SeppJ schrieb:
314159265358979 schrieb:
Ist bei mir eigentlich nur Motivationsmangel. Wie haltet ihr immer so lange durch bei euren Projekten?
Viele der Leute hier bekommen Geld dafür
.Ich meine da eigentlich private Projekte
Na, da musst du halt etwas machen, was dir Spass macht. Dann geht das ganz gut.
Das ist nicht das Problem, die Projekte an sich machen ja Spaß.
Was ich schon so alles angefangen und nicht beendet habe (teilweise auch schon mehrmals):
- IRC Daemon
- IRC Bot
- KIs
- Eigene Scriptsprache
- ...Irgendwas stimmt wohl bei meiner Vorgehensweise nicht. Drauf losprogrammieren ist wohl nur mit Plan im Kopf falsch.
P.S.: Könnte evtl ein Mod die Threads trennen?
-
Das Problem kenne ich mit der 64k-Intro, die ich seit Ewigkeiten schreiben will.
Sobald man das eigentliche Problem meint vollständig durchdrungen zu haben, vielleicht den Kern schon fertig hat, und der Rest sich nur noch nach Tipparbeit anfühlt (auch wenn Leute, die beim MBTI ein S und kein N haben, hier widersprechen würden), wirds teilweise öde.
Da helfen natürlich externe Motivationen wie Geld, Leute, die drauf warten, Wetten, die man Abgeschlossen hat, Erwartungen, die man in seinem Bekanntenkreis gesetzt hat, selbtgesteckt Ultimaten usw. Das ganze ist ja eine Wissenschaft für sich.
Aber auch aus Projekten, die man nicht vollendet, lernt man viel. Hauptsache ist, dass man das Vollenden von Projekten, bei denen nicht der Weg sondern das Ziel das Ziel ist, nicht verlernt.
-
Dieser Thread wurde von Moderator/in SeppJ aus dem Forum C++ (auch C++0x) in das Forum Rund um die Programmierung verschoben.
Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?Dieses Posting wurde automatisch erzeugt.
-
314159265358979 schrieb:
Das ist nicht das Problem, die Projekte an sich machen ja Spaß.
Ein Teil davon. Stundenlanges Suchen von Bugs und anstrengendes nachträgliches Einbauen von zusätzlichen Features ist aber die halbe Miete - oft die unspaßigere Hälfte. Bei Privatprojekten macht man halt gerne die Teile, die Spaß machen: Vom Entwurf bis zum "funktioniert-großteils". Danach verliert man etwas Motivation, weil's nicht mehr gefühlt voran geht
-
314159265358979 schrieb:
Das ist nicht das Problem, die Projekte an sich machen ja Spaß.
Was ich schon so alles angefangen und nicht beendet habe (teilweise auch schon mehrmals):
- IRC Daemon
- IRC Bot
- KIs
- Eigene Scriptsprache
- ...Irgendwas stimmt wohl bei meiner Vorgehensweise nicht. Drauf losprogrammieren ist wohl nur mit Plan im Kopf falsch.
Das Problem haben viele. Im Wesentlichen sind es (m.E.) 3 Gründe:
- Man unterschätzt die Komplexität des Projektes. Oberflächlich sieht es recht einfach aus, sobald man aber anfangen will bzw. einen kleinen Teil hat, sieht man, wie viel Arbeit eigentlich noch wartet.
- Man unterschätzt (gerade wenn man noch weniger Erfahrung hat) die Wichtigkeit eines guten Designs. Ja, draufloszuprogrammieren ist falsch, weil man sich bei entsprechender Komplexität früher oder später in Designprobleme verheddert. Dahinein spielt auch Punkt 1, da man die Komplexität unterschätzt, unterschätzt man auch das Design und somit die Notwendigkeit, überhaut eines zu erstellen.
- Es fehlt an Motivation, aufgrund der Nützlichkeit des Projektes. Wie oft hättest du denn den IRC Daemon oder den IRC Bot eingesetzt? Überhaupt einmal sinnvoll? Wenn man der Meinung ist, das Programm sowieso nicht zu brauchen, sinkt natürlich die Motivation.
Mein Tipp: schreibe ein paar einfach Programme. Wirklich einfache. Z.B. einen Taschenrechner, der Ausdrücke parst und Punkt-vor-Strich-Rechnung kann. Wenn du den hast, kannst du versuchen, Variablen und Funktionen hinzuzufügen. Aber lass es erstmal einfach, die Befriedigung, ein einfaches Projekt fertig zu stellen, ist weit größer, als ein schwieriges aufzugeben.
-
@314159265358979:
Ein paar IMO wichtige Eigenschaften für Hobby-Projekte:* Halbwegs klein. Wenn Dinge zu lange dauern, verliert man schnell das Interesse.
* Etwas was man selbst *verwenden* möchte, aber in der Form fertig nicht bekommt. Motiviert dranzubleiben, auch wenn die Arbeit am Projekt mal nicht so spannend ist.
* Etwas was man auch veröffentlichen kann. Und mit "kann" meine ich... es sollte realistisch sein wenigstens ein paar wenige User zu finden die das mal ausprobieren oder sogar verwenden. Das motiviert auch viel besser als wenn man nur so für sich dahinprogrammiert.Davon abgesehen...
Wie haltet ihr immer so lange durch bei euren Projekten?
Die grossen, langfristigen Sachen hab ich auch alle beruflich gemacht.
Privat schon länger nix mehr. Genaugenommen ist da nur ein Projekt was ich irgendwie relevant finde, aus dem Jahre 2004. Und ziemlich winzig.
Und ist auch aus Mangel an Alternativen entstanden: http://www.winamp.com/plugin/headplug/142337
(BTW: der Code ist halbwegs grausam, die Implementierung der Filter naiv, aber klanglich ist das Ding echt OK. Die ausreichende Umsetzung einer guten Idee sozusagen :))
-
Okay, nehmen wir als Beispiel den IRC Bot. (Nicht so groß wie die anderen Projekte und erfordert weniger Basiswissen als KI oder Parsen.)
Wie würdet ihr an dieses Projekt herangehen?
Was sollte man im Vorhinein planen?
Wie sollte man Code organisieren?
Womit fängt man beim Programmieren an?
...
-
314159265358979 schrieb:
Wie würdet ihr an dieses Projekt herangehen?
Erstmal möglichst genau das Verhalten spezifizieren. Also was er alles können soll und wie er es macht. Das ist reine Fleißarbeit, hilft aber enorm.
-
314159265358979 schrieb:
Okay, nehmen wir als Beispiel den IRC Bot. (Nicht so groß wie die anderen Projekte und erfordert weniger Basiswissen als KI oder Parsen.)
Wie würdet ihr an dieses Projekt herangehen?
Was sollte man im Vorhinein planen?
Wie sollte man Code organisieren?
Womit fängt man beim Programmieren an?
...Also zuerst mal (auch wenn es u.U. ungewohnt ist) nicht mit programmieren anfangen.
Sondern:1. Mache dir klar, was genau du willst, und stelle nicht zu hohe Anforderungen.
Ich weiß nicht, welche Art Bot es werden soll, ich nehme mal beispielhaft einen Quizbot. Was genau soll dieser Bot können? Quizfragen stellen, mit oder ohne Hinweisen, mit genauer Antwort oder "ähnlichster" Antwort, soll er auf Befehle reagieren und/oder automatisch starten, soll er in mehreren Channels oder gar auf mehreren Servern gleichzeitig aktiv sein? Bleib dabei auf den Boden. Es ist nur ein Quizbot, er braucht kein Scriptinginterface oder Web-Frontent, die Fragen kann er aus einer Textdatei laden und braucht keine Benutzeroferfläche. Sowas kann man später hinzufügen.
Nimm für den Anfang etwas ganz einfaches: der Bot liest seine Fragen aus einer Datei in der Form "Frage\nAntwort\nFrage\nAntwort...", mit "/quiz" wird eine zufällige Frage gestellt, die Antwort muss bis auf Groß- und Kleinschreibung exakt stimmen. Anschließend wird derjenige gepostet, der die Antwort nannte bzw. nach einer bestimmten Wartezeit wird aufgelöst. Mehr nicht. Diese klaren Anforderungen helfen dir u.a. auch, zu erkennen, wann du fertig bist. Mache dir erst danach über Erweiterungen und Verbesserungen Gedanken.2. Stelle ein Design auf, so genau wie möglich.
Wichtig hierbei ist, dass du den gesamten Bot betrachtest und nicht nur seine Kernkomponente (das Fragenstellen). Viele machen den Fehler, nur Teile zu betrachten, zu denken, dass diese sehr einfach umsetzbar sind, und den Rest zu vergessen. Beziehe also Quizlogik, IRC-Logik, Frageneingabe, Netzwerk usw. mit ein. Wenn er mehrere Channel gleichzeitig bedienen soll, wäre es sicher ratsam, Channel-/Nachrichtenlogik und Quizlogik zu trennen. Mache dir über so etwas Gedanken. Und nimm dir genügend Zeit für das Design, das ist sicher nicht an einem Nachmittag erledigt. Während du das Design entwirfst, kannst du dir auch überlegen, wie man es später einfach erweitern kann. Überteibe aber nicht, du musst ihn nicht soweit erweitern können, dass aus dem Quizbot irgendwann ein Channel-Servicebot wird.3. Programmieren
Jetzt kannst du anfangen zu programmieren. Sicher werden sich während der Programmierung noch Änderungen am Design ergeben, das ist nicht schlimm, da du den Grundstock aber schon durchdesignt hast, sollten sich aber keine großen Probleme ergeben. Du kannst mit der Grundkomponente an, also der eigentlichen Quizlogik anfangen (vielleicht soweit, dass der Quizbot schon auf der Kommandozeile ganz ohne IRC funktioniert) und baust den Rest später drumherum (in der Form, wie du es designt hast), oder aber auch z.B. mit der IRC-Funktionalität oder den Netzwerkkomponenten, das ist eigentlich egal.4. Dranbleiben
Nicht alles wird auf Anhieb funktionieren. Hier ist es jetzt wichtig, dass du nicht nachlässt. Mit den oben genannten Punkten wird dir der Punkt aber leichter fallen.
-
motivationsfördernd ist auch, was zu entwickeln, was es nicht schon 100-mal gibt. Also lieber eine lib für 3d-Grafikbeschleunigung per Auslagerung auf den Tastaturprozessor, als ein Launchpad oder einen Texteditor. Es sei denn, der Texteditor könnte was, was der emacs nicht kann
-
Also ich versuch mich mal an Punkt 1 - sag mir, ob das "zu hohe Anforderungen" sind, wie du sagst.
Der Bot soll keine Funktionalität eingebaut haben, er soll eine IRC-Schnittstelle für Plugins darstellen. Plugins (.dylib bei mir unter Mac OS) werden dynamisch geladen und können Event-Listener registrieren. Der Bot empfängt Nachrichten, verpackt sie in Events und ruft damit den entsprechenden Handler im Plugin auf.
Soweit mal die Grundidee.
-
314159265358979 schrieb:
Der Bot soll keine Funktionalität eingebaut haben, er soll eine IRC-Schnittstelle für Plugins darstellen. Plugins (.dylib bei mir unter Mac OS)
Mit der Plugin-Methode wird es aber schwer, ein abstürzendes Plugin daran zu hindern den kompletten Bot zum Absturz zu bringen. Dynamic libraries sind eine ziemlich enge Bindung, vielleicht ist bei IRC-Bot-Plugins eine lockere Bindung eine Überlegung wert.
-
Wie setzt man sowas denn um? Ich kenne nur dynamisch gelinkte Libraries.
(Kann man da überhaupt Klassen reinwerfen?)
-
314159265358979 schrieb:
Wie setzt man sowas denn um? Ich kenne nur dynamisch gelinkte Libraries?
Eine extrem lockere Bindung wäre zum Beispiel die Plugins über TCP mit dem Bot kommunizieren zu lassen. Dann wäre ein abstürzendes Plugin einfach weg, aber das wär dem Bot egal.
Allgemein sind separate Prozesse ganz gut, wenn man auf relativ einfache Weise Aufgaben stark trennen möchte. Dann übergibst du das Problem, die Prozesse separat zu halten, nämlich an das Betriebssystem, statt es selber lösen zu müssen.
Eine Alternative wären zum Beispiel Skript-Sprachen wie lua oder Javascript, die das Plugin in einer Sandbox ausführen können. Sandbox heißt hier, wenn das Plugin fehlerhaft ist, kann der restliche Bot trotzdem weiterlaufen statt automatisch mit abzustürzen. Dann kannst du aber die Plugins nur in dieser Skriptsprache schreiben, was die Plugins wieder etwas einschränkt.
edit: Einfacher als TCP, falls du unter Linux oder Mac OS X arbeitest, wäre eventuell ein fifo. Dein Bot würde dann für jedes Plugin einen separaten fifo anlegen und darüber mit den Plugins kommunizieren. Die Plugins laufen in separaten Prozessen und beenden sich, sobald der fifo weg ist (d.h. sobald der Bot weg ist).
Vorteil: Du lernst fifos kennen.
Nachteil: fifos sind vielleicht nicht die optimale Lösung hier: es gibt dann nämlich immer noch das Problem, was passiert, wenn ein Plugin sich nicht selbst beendet, obwohl der fifo weg ist. Das Problem würde ich aber vielleicht erstmal ignorieren.
-
Ich möchte aber die Möglichkeit, Plugins in C++ zu schreiben.
Reichen denn nicht Worker-Threads für die Plugins?
-
314159265358979 schrieb:
Ich möchte aber die Möglichkeit, Plugins in C++ zu schreiben.
Reichen denn nicht Worker-Threads für die Plugins?Ich hab meinem letzten Posting gerade noch ein edit hinzugefügt.
Threads können reichen, aber verglichen mit separaten Prozessen ist es schwieriger, das so abzusichern, dass ein abstürzendes Plugin nicht den ganzen Bot mitreißt.
Mit der TCP-Methode oder der fifo-Methode kannst du die Plugins in jeder Sprache schreiben, nicht nur C++.
Ein kleiner Nachteil der TCP- und die fifo-Methode ist aber auch, dass das Interface zwischen Bot und Plugin rein seriell ist: Du kannst keine Datenstrukturen direkt übergeben, du kannst nur Strings austauschen. Aber die Datenstrukturen bei einem IRC-Bot sind sowieso eher simpel, da sollte das kein zu großes Problem darstellen.
Ist natürlich nur ein Vorschlag. Vorteil wäre eben, du würdest dann etwas über fifos oder vielleicht auch andere Methoden der inter-process communication lernen.
-
Achso, ein fifo ist außerdem one-way. Jetzt wo ich drüber nachdenke, ist ein Socket wahrscheinlich doch sinnvoller, weil du vermutlich doch Daten in beide Richtungen austauschen musst, und für jede Richtung ein fifo anlegen ist nicht wirklich toll.
