Einfaches Client/Server-System à la SAP?
-
Danke Mechanics, für die wohlwollenden Worte.
Mein größtes VBA-Programm besteht aus ca. 2000 Zeilen. Ist jetzt nicht so groß, daß die Gefahr eines Spaghetti-Codes entsteht. Demnächst werde ich aber einen sehr komplizierten Programmteil von Grund auf neu schreiben, weil ich inzwischen wieder selbst dazugelernt habe und es unterm Strich die schnellste Lösung ist. Eine externe Dokumentation gibt es sowieso nicht, nur die Kommentare im Programm-Code.
Wegen dem Client-Server-System: Ich denke vorerst nicht daran eine tatsächlich verkaufbare Software zu entwickeln, denn dazu müßte ich eine Firma gründen, meinen derzeitigen eigentlich gut bezahlten Job kündigen (ich bekomme mehr als offiziell ausgebildete C++ und SQL Programmierer, wenn sie eine entsprechende ausgeschriebene Stelle annehmen würden); dann geht's noch weiter mit Kundensupport und ISO-Zertifizierung. Ich käme vom hundertsten in tausendste, aber all das ist nicht notwendig, denn mein Client-Server-Ding ist für mich nur ein Rahmenprogramm innerhalb dessen ich mir C++ und SQL selbst beibringe.
Sobald ich einen 2. oder 3.Programmierer beiziehe, geht es nicht doppelt oder 3-fach so schnell voran sondern eben weniger, weil man sich untereinander absprechen muß (Scrum?). Ist wie bei zwei Grafikarten im SLI-Verbund - läuft bestenfalls 80% schneller aber nicht 100% schneller.
Und wer eine rennomierte Client-Server Software sucht, kann ohnehin gleich zu SAP gehen. SAP hat 60000 Mitarbeiter, für irgendwas müssen die gut sein. Es wäre vermessen zu glauben als Einzelner alleine so eine Software zu erstellen.
-
Fletcher schrieb:
Und wer eine rennomierte Client-Server Software sucht, kann ohnehin gleich zu SAP gehen. SAP hat 60000 Mitarbeiter, für irgendwas müssen die gut sein. Es wäre vermessen zu glauben als Einzelner alleine so eine Software zu erstellen.
SAP Client-Server-Architektur ist der reinste Mist, wenn überhaupt ist das einzige technische gute ihre MaxDB. Außerdem brauchen sie ihre Programmierer nicht für den Kern sondern für die Business-Lösung.
-
Fletcher schrieb:
Ist es nicht.
So eine Aussage macht jetzt mich sprachlos! Ich habe jedenfalls 13 Jahre mit diesem System gearbeitet, und ich sehe was ich sehe. Es gab eine Übergangszeit, wo beide Systeme verfügbar waren und es haben ALLE bis zur letzen Minute mit dem alten System gearbeitet weil schneller.
Du schliesst von einem Programm auf alle Programme.
Das ist nicht klug.
-
Fletcher schrieb:
Wegen dem Client-Server-System: Ich denke vorerst nicht daran eine tatsächlich verkaufbare Software zu entwickeln, denn dazu müßte ich eine Firma gründen, meinen derzeitigen eigentlich gut bezahlten Job kündigen (ich bekomme mehr als offiziell ausgebildete C++ und SQL Programmierer, wenn sie eine entsprechende ausgeschriebene Stelle annehmen würden); dann geht's noch weiter mit Kundensupport und ISO-Zertifizierung. Ich käme vom hundertsten in tausendste, aber all das ist nicht notwendig, denn mein Client-Server-Ding ist für mich nur ein Rahmenprogramm innerhalb dessen ich mir C++ und SQL selbst beibringe.
Wie gesagt, was ich gesagt habe, bezieht sich nicht nur auf Programme, die man verkaufen will, sondern auch auf interne Lösungen. Als Lernprojekt wärs zwar ok, aber vielleicht gibts auch bessere Projekte zum Üben. Das Problem das ich sehe ist, dass du dabei zwar Programmieren lernen kannst (C++, SQL), aber von der Architekturseite kaum die Möglichkeit hast, eine wirklich brauchbare Plattform aufzuziehen. Du fängst also etwas an, wo von vornherein klar ist, dass es wenig durchdacht und suboptimal ist.
Fletcher schrieb:
In der Datenbank sind nicht nur die zu verwaltenden Daten abgelegt, sondern es gibt zusätzlich eigene Tabellen, wo in Form einer (noch zu erstellenden) Skriptsprache, der Client-Anwendung (.exe) mitgeteilt wird, welcher Text und welche Standard-Steuerelemente wo zu zeigen sind, und wie nach erfolgtem "Transmit" mit den eingegebenen Daten zu verfahren ist.
Das hört sich so nach den ersten Gehversuchen einer solchen Plattform an. Wird aber nicht der Weisheit letzter Schluss sein. Kann sein, dass nach paar Jahren Arbeit an deinem Programm dann immer mehr neue Ideen hast, wie man das flexibler und eleganter machen könnte. Vielleicht wirst du dann auch ähnliche Systeme kennenlernen und schauen wie die aufgebaut sind. Vielleicht wirst du dann auch völlig anders denken und merken, dass ASP.NET oder J2EE doch ganz interessante Plattformen sind, die dir weit mehr bieten, als deine erste "naive" Lösung.
Das soll jetzt kein Plädoyer für ASP.NET oder J2EE sein, ich würde keine Empfehlung abgeben, ohne mich intensiv in das Problem reingedacht zu haben (wobei ich persönlich bei einer Webanwendung zu J2EE und einem Application Server zu .NET tendieren würde, und wirklich nur bei einer ganz komplexen Anwendung mit sehr viel serverseitiger Logik zu C++, was ich hier nicht sehe). Ich will nur darauf hinweisen, dass andere schon auch mal deine Probleme hatten und vielleicht weitergedacht haben und dein Konzept hört sich wirklich ein bisschen naiv an.
Es passt auch zu deinem anderen Thread über "Personenabhängigkeit bei Software". Stell dir vor, du stellst das Progamm fertig und es funktioniert (durchaus realistisch) und wird eingesetzt (in deiner Firma wohl unwahrscheinlich?) und alle sind eine Weile zufrieden. Dann bist du weg und es läuft eine Weile und es sammeln sich neue Anforderungen an. Oder du bist vielleicht nicht ganz weg, hast aber keine Zeit oder kennst dich nicht gut genug aus, um die Anforderungen umzusetzen. Dann wird eine Softwareschmiede beauftragt, sich das Programm anzuschauen. Glaubst du, die werden mit sowas weitermachen? Die werden sicher sagen, was für ein Unsinn, sammeln wir zuerst mal die Anforderungen, dann machen wir ein Konzept auf der Basis bewährter Standardtechnologien. Aber vielleicht wollen die das gar nicht mit .NET oder J2EE umsetzen sondern wollen tatsächlich dein Client-Server System wiederverwenden oder erweitern. Dazu müsste die Basis entsprechend leistungsfähig sein. Eine Scriptsprache, die die Zuordnung von Datenbankspalten auf Steuerelemente in der GUI beschreibt, reicht bei weitem nicht aus. Die denkbaren neuen Anforderungen sind praktisch grenzenlos und dein Basiskonzept scheint mir sehr eingeschränkt zu sein. Somit würdest du nur eine Insellösung schaffen, die kaum erweiterbar ist.
-
@Zeus: Soll mir recht sein, daß du SAP als "Mist" bezeichnest; ich bin weder Freund noch Feind davon. Sowas artet aber sowieso in Glaubenskriege aus: Bentley vs Rolls-Royce, Boeing vs Airbus, Apple vs Microsoft, Fleischesser vs Vegetarier usw...
@Mechanics: Natürlich ist mein Ansatz "naiv". Zu Beginn möchte ich es absichtlich so einfach halten. Ich will einmal sehen wieviel Potential mein Ansatz überhaupt hat; sollten schon die ersten Gehversuche hinken, werde ich es sowieso mit etwas anderem Versuchen.
Bei mit meiner Idee geht es neben der Transaktionsgeschwindigkeit vor allem um den Benutzerkomfort bei der Eingabe: Ich möchte z.B. daß der einloggende User seine Short-Keys selbst bestimmen kann. Häufige Wörter und Phrasen sollen ebenfalls individuell einer Taste zugeordnet werden können. Geht alles im IE nicht!
Das Endprodukt so superflexibel wie möglich zu machen mündet am Ende darin, daß ich erst wieder eine Sprache wie ASP.NET entwickle (soferne ich das alleine überhaupt schaffe); das will ich bewußt vermeiden.
Bei unserem früheren uralt System, war die wesentliche Limitierung jene, daß man nur 80x25 Text anzeigen konnte. Die Schrift war pixelorientiert und immer scharf lesbar - ohne verschwommenen Clear-Type-Scheixx. Änderte man die Fenstergröße wurde automatisch die Schriftart geändert, sodaß die Buchstaben immer im richtigen Verhältnis zur Fenstergröße standen.Ich gehe gar nicht davon aus daß meine Anwendung irgendwann in der Praxis zum Einsatz kommt (nur Lern- und Übungsprojekt), deshalb ist es momentan meine 195.Sorge ob das Konzept in ferner Zukunft erweiterbar ist oder nicht.
Es kann ja z.B. sein, daß man mit ASP.NET und/oder J2EE in 10 Jahren in einer Sackgasse landet, die jetzt noch nicht ersichtlich ist. Sowas müßte ich bei jeder Plattform befürchten und dürfte daher mit gar keiner beginnen; Zurück zu Bleistift und Papier?
-
Fletcher schrieb:
Geht alles im IE nicht!
Ja ne, is klar.
Fletcher schrieb:
Zurück zu Bleistift und Papier?
Das sollte zumindest Dein Anfang sein!
-
Du wirst zu vieles in einen Topf
Es ist erstmal sehr unwahrscheinlich, dass man mit .NET oder J2EE in einer Sackgasse landet, das sind erstmal nur sehr allgemeine Frameworks, mit denen man alles machen kann. Wenn mit der Zeit neue Ideen entwickelt werden, können sie in die Frameworks integriert werden. .NET hat sich z.B. recht schnell weiterentwickelt und es wurden interessante Konzepte wie Linq oder PLinq aufgenommen. Natürlich könnte man aber darüber diskutieren, ob die ganzen Produkte an sich überleben, solche Diskussionen hatten wir ja schon. So gesehen wärs dann zukunftssicherer, alles "von Hand" in C++ zu implementieren. Was du ja auch machen kannst. Mir gings eigentlich primär überhaupt nicht um die Programmiersprache/Framework, sondern um dein Grundkonzept und die Architektur.
Ich sags dir nur, weil ich das alles auch schon selber durchgemacht habe. Auch oft mit "kleinen" Eigenentwicklungen angefangen, bis das alles immer schneller ausgeartet ist und ich bei jeder kleinen Änderung alles umbauen musste und irgendwann auch einsehen musste, dass die Idee an sich nicht ausgereift war. Ich will dich nicht davon abhalten, was zu schreiben oder zu lernen. Aber du solltest dir viel mehr Zeit nehmen, über dein Konzept nachzudenken. Versuch das im Detail durchzudenken, fang nicht einfach an zu implementieren. Du wirst (hoffentlich) merken, dass das nicht der Weisheit letzter Schluss ist.
-
Ich sags dir nur, weil ich das alles auch schon selber durchgemacht habe....
Ja, Danke. Freundlich gemeinte Hinweise nehme ich gerne zur Kenntnis :xmas1:
Bezüglich der Konzepte: Eine Zeit lang war das Konzept "wir speichern nur die letzten beiden Ziffern der Jahreszahl" ganz gut, bis kurz vor dem Jahr 2000 alle die Panik bekamen....
Oder: "Mehr als 640 kByte werden sie nie brauchen"....
Später: 32 Bits werden lange für die Speicheradressierung ausreichen. (Warum noch findet man jezt ständig x86- und x64-Versionen?)Ich will damit sagen, daß so wie manche heute irgendwen belächeln, wegen dem was vor 10-20 Jahren programmiert wurde, werden die gleichen Leute in 10-20 Jahren von anderen belächelt werden. Klopft euch also nie zu viel auf die Schultern!
Wenn man immer alles früher gewußt hätte, hätten ja schon die alten Römer auf Computern gearbeitet....
-
Fletcher schrieb:
Ich will damit sagen, daß so wie manche heute irgendwen belächeln, wegen dem was vor 10-20 Jahren programmiert wurde, werden die gleichen Leute in 10-20 Jahren von anderen belächelt werden.
Ja schon, aber was du machen willst wäre in etwa so, wenn du jetzt sagen würdest, niemand braucht mehr als 640KB Speicher, obwohl alle schon längst wissen, dass es nicht wahr ist
Wenn alle schon ein Stück weiter sind, macht es keinen Sinn, komplett von vorne anzufangen, ohne zu verstehen, was die anderen schon erreicht haben. Aber fang ruhig einfach mal an, du willst ja was lernen, und das wirst du wohl auf jeden Fall.
-
Um ehrlich zu sein:
mach das ganze mit PHP und Symfony.Das ist sehr einfach und du hast innerhalb eines produktiven Wochenendes einen funktionierenden Prototyp.
-
Fletcher schrieb:
Ich will damit sagen, daß so wie manche heute irgendwen belächeln, wegen dem was vor 10-20 Jahren programmiert wurde, werden die gleichen Leute in 10-20 Jahren von anderen belächelt werden. Klopft euch also nie zu viel auf die Schultern!
Wenn man immer alles früher gewußt hätte, hätten ja schon die alten Römer auf Computern gearbeitet....Du hast von der Materie keine Ahnung...
Du interpretierst diese Sachen allesamt komplett falsch.PS:
Niemand erwartet dass Software die man jetzt schreibt 1:1 in 20 Jahren noch modern ist. Aber wenn das Design der Software gut ist, dann laeuft sie in 20 Jahren noch - mit entsprechenden Anpassungen natuerlich, die aber eben durch das gute Design moeglich waren.OS X wird gemeinhin als ein sehr modernes Betriebssystem gesehen. Aber das Design von OS X enstammt direkt aus NeXTSTEP, welches 1989 released wurde. dh das Design von OS X ist bereits mehr als 20 Jahre alt und immer noch Top.
Der Kernel von Windows wurde 1993 veroeffentlicht - dh auch hier ist das Urdesign 20 Jahre alt.
Es gibt unzaehlige solcher Beispiele - gutes Design ist insofern zeitlos, als dass es sich an alle gegebenheiten anpassen laesst.
-
mach das ganze mit PHP und Symfony.
Das ist einmal eine vernünftige Antwort - Danke, werde ich mir anschauen.
Du interpretierst diese Sachen allesamt komplett falsch.
Vielleicht interpretierst du ja nur mich falsch....
-
Fletcher schrieb:
Du interpretierst diese Sachen allesamt komplett falsch.
Vielleicht interpretierst du ja nur mich falsch....
nein, tue ich nicht.
schau nochmal auf mein edit pls.
-
Ok, den Edit habe ich vorher nicht gesehen.
So gesehen hast du recht; Microsoft hätte sich also z.B:. die Metro-Oberfläche in Windows 8 sparen können."Symfony" ist, wie ich auf Wikipedia sehe, ein "Web-Application-Framework". Und wenn ich unter "Web-Application-Framework" nachschaue, steht dort ein interessanter Satz: Der Datenbankzugriff aus dem GUI heraus wird in der Informatik generell kontrovers betrachtet. Tja, deswegen ist hustbaer wahrscheinlich etwas giftig geworden.
Sollte ich also merken, daß "Symfony", oder etwas vergleichbares, das ist was ich eigentlich programmieren möchte, kann ich es mir ja sparen. Wichtig ist aber, daß mit Frontendanwendung die von mir schon geschilderten Besonderheiten (personalisierte Short-Keys und Phrasen oder ähnliches) umsetzbar sind.
-
Symfony ist erstmal auch nur ein Framework, deine Anwendung musst du schon selber schreiben. Aber solche Frameworks sind entsprechend durchdacht und zwingen dich mehr oder weniger, deine Anwendung sauber aufzubauen.
Das mit den Shortcuts ist jetzt kein Feature eines Frameworks. Ist doch klar, dass eine Webanwendung nicht ganz dasselbe wie eine Desktopanwendung ist. Vieles kann man aber ähnlich und vor allem ähnlich bequem machen. Shortcuts kann man mit JavaScript schon realisieren. Man kann das sicher auch konfigurierbar machen, musst dich halt selber drum kümmern. Sollte aber kein Akt sein.
-
Ist doch klar, dass eine Webanwendung nicht ganz dasselbe wie eine Desktopanwendung ist.
Ja, klar. Welchen Part Symfony nun erfüllt konnte ich noch nicht ausmachen.
Mich würde einmal die Desktop-Anwendung (kompilierte EXE) und deren Möglichkeiten interessieren.Zur Info: Die Terminal-Emulator Software an meinem Arbeitsplatz war folgende http://www.gar.no/en/products/glink-for-windows/features
-
Fletcher schrieb:
Ja, klar. Welchen Part Symfony nun erfüllt konnte ich noch nicht ausmachen.
Mich würde einmal die Desktop-Anwendung (kompilierte EXE) und deren Möglichkeiten interessieren.Symfony ist dein Backend.
Es bietet dir aber zusammen mit einer guten JavaScript Library alles was du fuers Frontend brauchst.Das coole daran:
Datenbank Modell, View, Kommunikation zwischen Client/Server, etc. ist alles bereits fix und fertig.Ob es jetzt Symfony oder Rails oder sonstwas ist, ist dabei egal.
Du brauchst keine exe Datei fuer den Client - das macht der Browser schon. Der Browser ist der ideale Client fuer sowas - denn die Leute kennen ihn, er wird konstant weiterentwickelt und er nimmt dir enorm viel Arbeit ab.
Aber du haengst dich gerade an einem Client Feature auf. Sowas ist uninteressant. Wenn deine Plattform steht - dann sind Client Features trivial hinzufuegbar.
PS:
Vergleiche dein System mal mit Facebook. Auf einer abstrakten Ebene natuerlich und du wirst sehr viele Gemeinsamkeiten finden.
-
Danke für die Erläuterungen.
Du brauchst keine exe Datei fuer den Client - das macht der Browser schon.
Tja, dann bringt mir Symfony doch wieder nichts was nach meinem Geschmack wäre.
Die gängigen Browser sind für Webseiten konzipiert und dieses Konzept halte ich für professionelle Anwendungen im professionellen Umfeld nicht geeignet. Die Art und Weise wie man auf ebay oder amazon herumdaddeln kann ist vielleicht für den Privatnutzer ausreichend, aber müßte ich den ganzen Tag hauptberuflich auf so einer Plattform arbeiten würde ich krank werden.Ganz anderes Beispiel: Online-Casinos
Wer meint, daß er dort mitspielen möchte (trotz der Tatsache daß man dort langfristig immer nur verliert), muß sich meistens eine Desktop-Software herunterladen (compilierte exe), wo z.B.: der Roulette-Tisch grafisch besonders schön dargestellt wird und man oftmals per direktem Tastenzugriff Aktionen tätigen kann. Das wäre dann ein dezitierter Browser mit sehr eingeschränkten Möglichkeiten, weil es hier nur ums Roulette-Spielen geht, aber dieses gebotene User-Handling wirst du mit einem Browser und Java niemals erreichen; sonst würden diese Desktopanwendungen gar nicht angeboten werden, wenn es mit dem Browser auch funktionieren würde.Nocheinmal: Bei meinem Vorhaben geht es in erster Linie um gute haptische Interaktion mit dem User. Transaktionen müssen auch im lauten, dreckigen, vibrierenden Bergwerk mit nur einer Hand (manchmal ohne Maus!) getätigt werden können.
-
-
Fletcher schrieb:
Die gängigen Browser sind für Webseiten konzipiert und dieses Konzept halte ich für professionelle Anwendungen im professionellen Umfeld nicht geeignet.
Das ist falsch.
Der aktuelle Trend geht dazu immer mehr ins Web zu legen - weil es unheimlich praktisch ist.
Man kann ganze Office Anwendungen als Webapp laufen lassen.Der Browser kann alles was notwendig ist. Du kannst sogar notfalls mit OpenGL die Grafik machen wenn dir wirklich langweilig ist.
Nocheinmal: Bei meinem Vorhaben geht es in erster Linie um gute haptische Interaktion mit dem User. Transaktionen müssen auch im lauten, dreckigen, vibrierenden Bergwerk mit nur einer Hand (manchmal ohne Maus!) getätigt werden können.
Und nocheinmal:
Der Browser hat deine erste Anlaufstelle zu sein.
Der Browser kann mehr als du denkst.Gerade wenn du Bergwerk sagst, spricht wieder unmengen fuer den Browser - denn ein Touchlayout dass auf allen Geraeten laeuft, ist im Web trvial.
Das coole ist ja, dass du billigsdorfer Hardware nehmen kannst, es ist komplett egal was - denn ein Browser laeuft sicher darauf. Aber ob es jetzt Android oder ein Windows CE ist, ist komplett egal. Sogar irgendwelche Custom BSDs waeren kein Problem: es braucht nur einen Browser und den hat man ueberall.
Aber wozu rede ich mir hier den Mund fusslig... Du scheinst alles eh besser zu wissen.
