Kundenverwaltungssoftware

Elanar

Newbie
Registriert
März 2013
Beiträge
5
Hallo.

Ich möchte mich mal wieder mit dem Thema Programmieren auseinander setzen.

Dazu plane ich eine Kundenverwaltungssoftware zu realisieren.

Zu meinen Kenntnissen:
Ich bin recht talentiert im Umgang mit PHP und MySQL, auch wenn ich mir immer wieder Hilfestellungen holen muss. Ich bringe mir quasi alles selbst bei, Learning by Doing ist das Prinzip dahinter.

Bislang kamen so ein CMS und eine kleine Datenbanksoftware zustande. Nichts besonderes, aber ich bin dennoch stolz drauf. An Programmierkenntnissen wars das auch schon, was aber ja nicht heißt, dass man nicht neue Dinge lernen kann.

Ich möchte also eine Kundenverwaltungs"software" schreiben. In diese soll nach und nach eine Kalenderfunktion, eine Anbindung an ViciDial, ein kleiner Mailclient, und noch einige Extras eingebunden werden um die tägliche Arbeit mit Kundendaten zu erleichtern. Auch ein späterer Live-Zugriff der Kunden (zum Beispiel Kampagnenauswertungen etc.) über eine Webseite stehen zur Debatte. Und ich möchte dabei explizit nicht auf eine bereits bestehende Lösung zurückgreifen, sondern "das Rad neu erfinden".
Nun dachte ich zunächst an die Realisierung mittels PHP. Die Frage nach der Sicherheit stünde, zunächst, nicht im Raum, da die "Software" nur lokal eingesetzt wird. Doch mit zunehmendem Funktionsumfang soll sich das natürlich eventuell ändern.

Stellt sich also die Frage, in welcher Sprache ich mein Projekt umsetzen möchte. Da ich bislang außer PHP und MySQL nichts kenne, ist es überhaupt nicht schlimm, mir eine neue Sprache von Grund auf anzueignen.

Deshalb meine Fragen:

Welche Programmiersprache haltet ihr für angemessen und warum?
Wie sieht es, falls nicht in PHP umgesetzt, mit der Einbung von PHP-basierten Lösungen aus? (ViciDial z.B.)

Einige werden jetzt sicher denken und mir wahrscheinlich raten "lass die Finger davon", aber es geht mir nicht um eine professionelle Lösung, sondern darum, meinen Horizont zu erweitern. Ich schreibe diese "Software" für mich und nicht für den kommerziellen Einsatz. Ich fange gern bei 0 an und bringe mir wesentliche Dinge selbst bei, man weiß ja nie, wofür man das nochmal gebrauchen kann.

Ich freue mich auf eure Ratschläge!
 
Die Frage nach welcher SW ist meiner Meinung nach noch zu früh, da das Projekt noch sehr ungenau definiert ist.
Wenns "nur für dich" ist, dann würd ich einfach schauen was geht mit dem was ich kann (PHP/MySQL).
Dann später konkret fragen: geht das mit XY leichter/einfacher.
mM
 
Es ist hier ungenau definiert. In meinem Kopf ist aber klar was ich möchte.

Ich möchte ungern an einen Punkt gelangen, wo ich mit "dem was ich kann" nicht weiter komme und dann quasi von vorn beginnen muss. Da lerne ich lieber eine ne eProgrammiersprache von klein auf und ärgere mich mit dem lernprozess herum, als am Ende doof da zu stehen.

Ich würde ja auch kein Spiel anfangen in Java zu Programmieren nur weil ich es kann, um dann im laufe des Projektes festzustellen, dass Java aber nicht ausreicht, um ein hochwertiges 3-Ballerspiel zu programmieren.

Ich denke du verstehst was ich meine oder?
 
Der logische Verstand löst das Problem doch schon...

Du kannst deiner Aussage nach PHP, also warum erst eine neue Sprache lernen, wenn du sofort loslegen kannst? Zumal dir in einer neuen Sprache dann erstmal die Erfahrung fehlt.
Umsetzbar ist es mit PHP auf jedenfall, ich glaube du bist dir noch nicht wirklich bewusst, was PHP kann und wieviel darin bereits gebaut wurde und auch genutzt wird.

Bezogen auf die Sicherheit: PHP ist nicht unsicher, es ist genauso sicher, wie jede andere Sprache. Wenn deine Anwendung nachher unsicher ist, dann liegt es an dir, und wäre auch mit Java, Python, Ruby oder whatever so.
 
Gleich vorweg: Ich rede hier nicht PHP schlecht. Man kann das sicher auch alles mit PHP machen, aber da du wohl gern was Neues ausprobieren willst, hier mal ein Alternativvorschlag.

Ich finde Java dafür am attraktivsten. Es ist in diesem Bereich so sehr etabliert, dass du für jeden Firlefanz nützliche Frameworks und Libs finden wirst. Auch wenn du das Rad neu erfinden willst, musst du in bestimmten Bereichen Abstriche machen. Es macht keinen Sinn ein eigenes Persistenz-Framework zu schreiben. Abgesehen davon, dass das schon in den Bereich Rocket-Science fällt, wird allein das dich schon unglaublich viel Zeit kosten und ist mit endlos viel Theorie verbunden, die du dir beibringen musst.

Selbst wenn du Frameworks verwendest, gibt es dabei noch enorm viel zu lernen und zu verstehen. Trotzdem abstrahiert die EE-Spezifikation schon einiges, um dir zu ermöglichen dich auf deine Businesslogik zu konzentrieren. Dazu gehört unter anderem auch Sicherheit (was nicht bedeutet, dass du das Thema unter den Tisch fallen lassen kannst).

Schnapp dir probeweise mal einen Tomcat (später JBoss oder GlassFish) und probiere rum. Dann bastelst du ein Frontend-Framework wie Wicket oder Spring MVC dazu und siehst dich in dem Bereich etwa um. Dann kannst du z.B. mit Hibernate mit der Persistenz experimentieren oder du persistierst spaßeshalber erstmal in XML (z.B. JAXB oder XML beans).

Wenn du richtig "modern" an die Sache herangehen willst, dann kannst du auch direkt auf Scala mit Scalate oder so setzen. Da ist es aber schwieriger, wenn du irgendwann andere Leute brauchst, die mitarbeiten, weil Scala einfach noch nicht so verbreitet ist.

Auch sehr interessant in diesem Zusammenhang ist das Play-Framework.
 
Zuletzt bearbeitet:
Tumbleweeds Idee mit Java ist nicht übel, aber ich glaube das ist mit Kanonen auf Spatzen schießen. Java Server-Anwendungen sind zu deutlich mehr in der Lage als "nur" ein CRM.

Ich würde sagen: Bleib bei PHP, aber setz dich direkt mit einem der großen Frameworks wie Symfony2 oder dem Zend Framework auseinander. Die Herangehensweisen werden sich dabei wahrscheinlich signifikant von deinen bisherigen unterscheiden, aber immerhin bist du mit der Sprache vertraut.

Was die Möglichkeiten von PHP angeht: So ziemlich alles, was du brauchen könntest, ist damit möglich. Java wäre in manchen Bereichen performanter. Node.JS wäre bei Event-Steuerung (Web Apps in Echtzeit) und hoher Parallelität besser. Ruby (in Verbindung mit Rails) könnte in etwas hübscherem, kürzerem Code resultieren. Eine native Anwendung direkt in C oder C++ wäre zu extremer Komplexität bei gleichzeitig extremer Performance fähig.
Trotz allem spricht gar nichts gegen PHP. PHP auf einem gut eingerichteten Apachen mit einem gut konfigurierten MPM sowie einem stabilen OpCode-Cache rennt flott genug. Eine SQL-Datenbank ist bei deiner Aufgabenstellung diesen hochgehypten NoSQL-Lösungen wie Redis deutlich überlegen. Ich würd nur evtl. von MySQL absehen und statt dessen auf MariaDB wechseln. Ist vollständig kompatibel zu MySQL, aber dabei deutlich performanter. PostgreSQL wäre auch eine Option. Ist aber im Endeffekt egal, dein PHP-Framework wird sicherlich eine Abstraktionsschicht für die Datenbank bieten, so dass du am Ende sogar SQLite verwenden könntest, ohne dass du etwas umschreiben musst.


@Fuselpower
Delphi ist proprietärer Rotz mit unnötiger Verzahnung zu Microsoft. Versuch mal eine Delphi-Anwendung auf einer Nicht-Windows-Maschine zu starten, das wird gar nichts.
Der clevere Anwendungsentwickler schreibt portierbaren Code, damit er nie an ein einzelnes Betriebssystem gefesselt ist. Windows Server ist, verglichen mit BSD und Linux, eine wandelnde Sicherheitslücke und ein Hardware-Loch. Totale Zeit- und Geldverschwendung.
 
Zuletzt bearbeitet:
Auch mit Delphi kann man plattform-unabhängig schreiben.
Jedoch geht es mit der VCL deutlich komfortabler, ein Client/Server Modell zu erstellen.
Ebenso ein Intranet/Internet/eMail basierendes Modell.

Und Windows-Server bzw. ein anderes Server-BS ist für diese Art der Entwicklung gar nicht notwendig.
 
Daaron schrieb:
Node.JS wäre bei Event-Steuerung (Web Apps in Echtzeit) und hoher Parallelität besser.

Das kann man auch mit Java haben, nennt sich Vert.x und ist seit neustem nun auch Projekt der Eclipse Foundation. Die enorme Skalierbarkeit von Node.js und Vert.x hängt eher weniger von der Sprache ab als vom Prinzip des Eventloop und nicht blockierenden, asynchronen I/O-Zugriffen. Ich wollte es nur erwähnen, da ich mir kaum vorstellen kann, wie man ohne Schmerzen mit Javascript größere Projekte realisieren soll. Vert.x ist btw. polyglott und unterstützt neben Java auch Groovy, Python, Ruby, Java-/Coffescript bald auch Scala (alles in der JVM).

Aber das nur am Rande, das ist nichts, was der TS sucht. Beide Frameworks sind eigentlich lediglich Web-/TCP-Server, um alles, was darüber kommt, muss man sich selbst kümmern.
 
Fuselpower schrieb:
Und Windows-Server bzw. ein anderes Server-BS ist für diese Art der Entwicklung gar nicht notwendig.
Wenn das Ziel eine Web-basierte Kundenverwaltung ist, dann muss das Projekt sehr wohl auf einem Server laufen... und ein MS Server ist da eben die allerletzte Wahl.

carom schrieb:
Ich wollte es nur erwähnen, da ich mir kaum vorstellen kann, wie man ohne Schmerzen mit Javascript größere Projekte realisieren soll.
Hm. Ich hatte noch nie Zeit & Nerven, wirklich mal tief in Node.JS einzutauchen, aber das was ich mir angeguckt habe hat mich schon ziemlich beeindruckt. Außerdem kannst du ja die bekannten Frameworks wie Mootools auch mit Node.JS koppeln. Das sollte selbst komplexe Anwendungen deutlich vereinfachen.
Irgendwie hätte ich Bock, ein CMS (z.B. einen Contao-Clone) auf Basis von Node.JS zu schreiben, aber mir fehlt die Zeit. Wenn du 8h am Tag PHP schreibst oder dich mit Magento rumärgerst, dann willst du zuhause nur noch 1-2 Bier trinken und dich mit ner Runde Battlefield abreagieren.
 
Ich wollte dir node.js keinesfalls mies machen, probier es ruhig aus wenn du die Zeit finden solltest. Mit express.js gibt es bereits ein brauchbares Web Application Framework für node.js, das könnte dein Vorhaben beschleunigen.

Es geht mehr um die Frage, ob serverside javascript wirklich sein muss, was in den letzten drei Jahren auch die Hauptkritik an node.js ausmachte. Ich hatte an dieser Stelle eigentlich einiges dazu geschrieben, dann aber gemerkt, dass es in diesem Thread schlicht off-topic ist. JS ist einfach ein Kuriosum. Leidenschaftliche Darlegungen sind hierzu nicht rar im Netz zu finden. Dabei belasse ich es mal an dieser Stelle. Aber auch technische Limitierungen nerven. Während man beispielsweise bei node.js aufgrund von Javascript den Prozess hässlicherweise forken muss, um alle CPU-Kerne auszulasten, übergibt man bei Vert.x einfach nur die Anzahl der gewünschten Instanzen und die JVM, die dafür gebaut und optimiert wurde, regelt den Rest. Aber das nur am Rande, mit JS hat man noch ganz andere Probleme.

Aber wie gesagt, für den TS halte ich weder Vert.x, noch node.js für angebracht. In seinem Szenario ist er mit typischen Web application frameworks zehn mal produktiver, und PHP kennt er bereits. Vor allem müsste er sich bei den beiden event-driven Ansätzen erst mal herantasten, was er im Event-Loop alles machen darf, ohne dass dieser durch eine einzige Anfrage blockiert wird und alle anderen Nutzer in die Röhre schauen. Die Denkweise ist einfach eine ganz andere als das one-thread-per-request Modell.
 
Zuletzt bearbeitet:
Zurück
Oben