Objection, your honor!
Alter arroganter Sack-Kappe aufsetz
raeusper
an Wasserglas nipp
Buchi hat geschrieben:Auch mal meinen Senf dazu abgeb
Vorab mal eine Info:
Ich erstelle beruflich Webaplikationen bei Siemens. Die Technik ist nie das Problem, denn da gibts so gut wie immer Lösungen. Problematisch ist die Struktur, die Logik hinter einer Anwendung.
Ack.
Buchi hat geschrieben:René hat geschrieben:Von Skripten, die auf Perl oder CGI basieren, halte ich nichts.
100% ACK
Hat heute nichts mehr auf Webservern zu suchen.
Eigentlich wollte ich diese Diskussion hier vermeiden, aber dass will ich so einfach nicht stehen lassen.
CGI ist hinueber. Ack.
Aber hier den Einsatz von modernen Scriptsprachen so pauschal als Fehler zu kategorisieren, halte ich fuer bloedsinnig.
Perl, python und ruby integrieren alle sauber in Apache. Alle bieten teilweise mehrere Application-Frameworks.
Was ist die Alternative?
PHP? Keine Trennung zwischen Code und Repraesentation. Setzen, 6!
JSP? Das selbe Problem wie PHP.
Servlets? Ok, an jsp fuer's Templating kommt man in dem Fall nicht herum, und wenn man klare Guidelines 'rausgibt, dass ausschliesslich Servlets zu benutzen sind, und jsp keinen eigenen Kram machen darf, ist das ein Weg.
Viel Spass, beim installieren von Tomcat oder einem seiner haesslichen kommerziellen Brueder.
René hat geschrieben:Generell bin ich auch von vorgefertigten "Out-of-the-Box" Skripten nicht so begeistert. Man frickelt im Entefekt genau so lange an diesen Skripten rum, damit sie in die eigenen Skripte perfekt passen, als wenn man diese komplett selber entwickelt. Zum finden von Lösungsansätzen für komplizierte Skripte sind sie aber gut zu gebrauchen.
Ebenfalls 100% ACK
Nope!
Hier handelt es sich mit gutem Willen um ein fettes Vorurteil, bei boeser Betrachtung bestenfalls um Arroganz.
Bist Du sicher, dass Du's von Null angefangen, besser und schneller kannst, als ein aktives Team von einem Dutzend Leuten die ueber die letzten 2 Jahre an der Software gearbeitet haben?
Wieso setzt Ihr dann z.B. phpBB ein, statt einer selbst gebauten Loesung?
No Way!
Wenn Du in der Softwareentwicklung bist, weisst Du selber, dass man am Beginn eines Projektes noch nicht einmal eine Vorstellung hat, ueber welche Probleme man spaeter stolpern wird, Planung hin oder her. Ich verdiene jetzt seit '87 meine Kohle mit Programmierung, seit '95 unter Anderem im Web, und ich fass' mir trotzdem jedesmal wieder an den Kopf, wenn mich ein bloedes Detail nach 2 Wochen Arbeit in den Arsch beisst. Die Chance, dass das bei einem lebendigen Projekt vorher schon 100 anderen Leuten passiert, und der Bug gefixt ist, ist verhaeltnismaessig hoch.
Usermanagement, Permissions, Session-Handling, Content-Management, etc. Wenn Du sowas 'mal eben nebenher in Deiner Freizeit bauen moechtest, zieht
mindestens ein Jahr in's Land, bevor Du produktionsreifen Code hast. Selbst, wenn Du Mr. Ubercoder auf die Stirn taetowiert hast.
Dann doch lieber auf ein gut gepflegtes, lebendiges Projekt zugreifen, und da mit entwickeln. So funktioniert OpenSource.
Klar kann man auf die Schnauze fallen, wenn man die erstbeste Codebase nimmt, 'reinschaut, und das Kotzen bekommt, aber mit ein bischen Recherche und Kontakt zu den aktuellen Entwicklern, merkt man ganz schnell, ob ein Stueck Software als Basis geeignet ist oder nicht. Und in dieser Zeit hat man's sicher nicht selbst geschrieben.
Schau' Dir die Demo an, die auf meinem Dialup laeuft. Das hat insgesamt, mit Download, konfiguration, farben von SVrider.de klauen, Struktur einrichten insgesamt vielleicht 3 Stunden gedauert. Und dabei hab' ich noch keine einzige Codezeile angefasst.
Buchi hat geschrieben:Generell zum Thema Wiki:
Die heute zur Verfügung stehenden Wikis sind mittlerweilen sehr benutzerfreundlich und im Funktionsumfang sehr gut. Prinzipiell stellt sich aber hier eine ganz andere Frage:
Wer darf in das Wiki schreiben?
Wenn alle schreiben dürfen, dann ist das Wiki wieder ein Forum.
Nope, ist's nicht. Im Wiki schreibt man ja nicht miteinander, sonder gemeinsam
ueber etwas. Ganz anderes paar Schuhe.
Buchi hat geschrieben:Ein Forum gibts schon, brauchen wir also nicht mehr. Hier macht ein Wiki nur Sinn wenn es ein paar Kümmerer gibt, welche sich den Einträgen annehmen. Entweder werden diese dann per PN auf ein Thema aufmerksam gemacht oder sie ziehen selbst Information gebündelt aus dem Forum ins Wiki.
Wieso? Traust Du den Community-Members so wenig? Versuch's doch 'mal mit ein wenig Selbstregulierung. User A schreibt Bloedsinn, jemand fragt dazu im Forum nach, diverse Leute diskutieren den Kram, und einer der sich aufraffen kann, korrigiert den Artikel. Wen's interessiert, der kann sich anschauen, was geaendert wurde, usw.
Ja, ich wuerde auch Moderatoren benennen. Das war einer der Gruende, weshalb ich eine dem Forum aehnliche Struktur vorgeschlagen hatte. Aber ein Moderator muesste nur eingeschaltet werden, wenn z.B. Hatespeech oder sowas angelegt wird. In dem Fall greifen die Moderatoren ja im Forum auch ein.
Buchi hat geschrieben:Wie René schon schrieb ist es immer auch mit Aufwand verbunden bestehende Aplikationen in dieses doch schon recht komplexe Konzept von SVrider zu integrieren. Hier würde ich auch eher den Ansatz gehen die schon bestehenden Skripte (Tips, Linkliste usw.) so zu erweitern, das Kategorien angelegt werden können. Dieser Aufwand dürfte sich in Grenzen halten, die Integration in SVrider besteht damit bereits und es ist jederzeit beliebig an die eigenen Bedürfnisse anzupassen.
Mit der derzeitigen Loesung haben die Moderatoren oder Ops mehr aktive Arbeit, als mit einem Wiki, weil sie jedesmal springen muessen, wenn sich 'was aendern soll.
Wer pflegt alte Dokumente von Leuten, die nicht mehr aktiv sind?
Was die technische Integration betrifft: Ich habe keine Ahnung, was bei Euch noch alles unter der Haube passiert. Fuer mich sind ja eigentlich nur Homepage und Forum als fertige Dienste sichtbar. Insofern, nicht schlagen, falls ich die Komplexitaet von svrider.de unterschaetze.
Aber dinge wie uebergreifende Userverwaltung sollte nicht das Riesenproblem sein, schliesslich ist der Code aller beteiligten Elemente ja einsehbar.
Look and Feel sind eigentlich bei allen Wikis konfigurierbar (Stichwort Skins).
Was fehlt da noch?
Ich glaube, Ihr denkt alle zu kompliziert.
TODO:
- Entscheiden welches Wiki
- Installieren, Grundstruktur einrichten
- Look & Feel an die Community/Homepage/Forum anpassen
- Userbase importieren, oder eine Auth-Bridge 'rueber in's Forum bauen
- Link auf der Homepage anlegen
- In allen Unterboards announcen, und schauen, was die Community damit anfaengt.
Hmm, das wahren jetzt eher mein EUR 31,78 statt 2ct
