Einfaches Client/Server-System à la SAP?
-
Ok, nochmal zum mitschreiben: Den App-Server lässt du aus Zeitgründen weg, aber du lernst schnell mal eben C++ um deine Anwendung zu schreiben?
Wenn du ohnehin überlegst, einen MSSQL-Server zu verwenden, schreib dein GUI einfach in C# und fertig. Wenn du ohnehin bei Microsoft-Zeugs bleibst, nutze auch deren Toolchain, das macht alles viel bequemer und einfacher und für Windows-GUI-Zeugs ist C# einfach unheimlich praktisch.
Alternativ kannst du auch eine Sprache verwenden, die du schon kennst. Überleg dir einfach, ob du primär eine neue Sprache lernen möchtest oder das Projekt fertigbekommen möchtest.
-
Zum Glück ist es so, daß ich hier nicht unter Zeitdruck stehe und gar nichts fertigbekommen muß.
Vielleicht ergeben sich bei mir auch neue Lebensumstände, die helfen dieses Projekt zu beschleunigen, oder aber auch Umstände die mich dazu zwingen das ganze komplett zu vergessen......
Es wäre nur ein mögliches Endprodukt das mir vorschwebt. Auf dem Entwicklungsweg dorthin, liegen noch viele andere Steine im Weg, wie z.B. wie erstelle ich einen Button dynamisch zur Laufzeit? Wie lasse ich ihn auf Mausereignisse reagieren? usw. (Das will ich selbst herausfinden, und wenn ich nicht schaffe lasse ich es ohnehin bleiben)Um native Windows-Anwendungen zu schreiben, habe ich mir einmal den Windows-SDK runtergeladen. Dort ist C++ enthalten (und nur C++); es wird schon einen Grund haben warum das so ist. Wenn Microsoft es mir wirklich einfach machen möchte, müßten sie Visual Basic so gestalten, daß man auch nur damit native x86-Anwendungen erstellen kann. Mit VB 6.0 im Jahr 2000(?) ging das noch!
Das nächste ist das WinAPI: Wenn es auf Windows laufen soll, wäre es nicht schlecht zu wissen, wie es "bedient" werden muß. Auch bei PureBasic hätte ich mich mit der WinAPI vertraut machen müssen, weil ohne dem offenbar nichts geht.
Erst wenn ich soweit bin, daß ich Fenster und Steuerelemente nach belieben gestalten und manipulieren kann, kommt SQL - "zum Darüberstreuen".
Es ist alles im Moment rein persönliches Interesse "zum Privatvergnügen", da werde ich mich selbst nicht unter Druck setzen. Wäre ich arbeitslos und würde einen IT-Job suchen, sähe die Sache schon anders aus.
-
Ehrlich gesagt klingt das stark so, als hättest du dir ein bisschen zu viel vorgenommen.
WinAPI und C++ gleichzeitig zu lernen ist keine gute Idee. Das 2012 noch für ein komplett neues Projekt einzusetzen auch nicht; niemand schreibt mehr Anwendungen in WinAPI. Aber frag wegen deiner GUI- und sonstigen Fragen bitte lieber in einem anderen Subforum hier nach. Hier gibt's weniger Windows-GUI-Spezialisten.
Deine DB-Fragen hat hustbaer dir schon kompetent beantwortet, seinen Ausführungen ist nicht mehr viel hinzuzufügen: Du kannst dich entweder auf die Empfehlungen von Leuten mit viel Erfahrungen verlassen oder sie ignorieren. Für letzteren Fall brauchst du aber eigentlich keine Forenposts.
-
Fletcher schrieb:
Daß C# 10x einfacher ist als C++ wird schon stimmen, aber es ist eine Sprache die das .NET-Framework braucht - will ich nicht!
Grund?
Und wenn ich schon eine neue Sprache lerne, dann kann es ruhig gleich C++ sein; ich habe nämlich schon einmal irgendwo in einer vereinfachten C-Synthax programmiert (es war nicht C#), war nicht so schwer.
Das kann jetzt nicht dein Ernst sein?
*Hab schon mit was mit geschwungenen Klammern gemacht und das war OK, also kann C++ nicht so schwer sein.
*Wo ist der Smiley der sich mitm Hammer aufn Kopp haut, ich brauch den grad dringend!Du unterschätzt MASSIV die komplexität von C++.
Am Ende soll eine saubere native x86-Anwendung rauskommen - im Idealfall gibt es nur eine EXE-Datei die nicht einmal installiert werden muß.
Dann such dir irgend ein RAD Toolkit das eigenständige .exen ausspucken kann.
Wobei ...Ich habe auch schon überlegt, ob ich nicht PureBasic dafür verwende; nur ist mir das zu unsicher im Hinblick auf Support in ferner Zukunft. (Hinter PureBasic stehen angeblich nur 2 Leute).
...DAS Problem hast du bei den meisten RAD Tookits auch. Wobei hinter den meisten mehr als 2 Leute stehen. Trotzdem kann es schnell passieren dass ein solches Produkt eingestellt wird. Und da die oft ne eigene Programmiersprache haben, bzw. ein eigenes Framework mitbringen von dem alles abhängt, steht man dann auch ziemlich blöd da.
Was mit PureBasic auf jeden Fall geht ist native x86-Anwendungen zu erstellen, und sogar die gesamte PureBasic-Entwicklungsumgebung kann ohne Installation direkt vom USB-Stick aus gestartet werden. Ideal um auf eingeschränkten Firmen-PCs das eine oder andere kleine EXE-Tool zu programmieren um dort lästige Systemeigenschaften zu auszutricksen.
Ist jetzt die Frage anhand von was du entscheiden willst in welche Technologie du die nächsten 2-5 Jahre deiner Freizeit investieren willst.
In eine Technologie die Zukunft hat und für sich genommen Sinn macht, oder in etwas mit dem man die beknackte Anforderung "ich darf nix installieren" erfüllen kann.
-
Im Vergleich PC zu Commodore C64, entspricht .NET dem C64-BASIC und C++ der Maschinensprache des C64. Spiele für den C64 konnten nur direkt mit der Maschinensprache geschrieben werden, da der ganze BASIC-Overhead so viel Rechenleistung und Speicherplatz beanspruchte, daß eben keine "komplexen" Spiele mit BASIC möglich waren.
Auf meinem PC ist eine .NET-Anwendung installiert - es ist die "aquasuite" von Aqua-Computer - mein PC ist nämlich wassergekühlt. Beim Umschalten der verschiedenen "Masken" am Bildschirm hat man das Gefühl man blättert ein Buch um, weil es genau einen so kurzen Moment dauert bis der Bilschirmbereich neu gezeichnet worden ist. Sie verhält sich generell etwas träge.
Wenn ich .NET verwende kann ich gleich bei Excel-VBA bleiben, denn .NET ist nur der Mittler zum eigentlichen System. Jeder in C# oder VB geschriebene Code wird in .NET nocheinmal umgewandelt. Damit ja alle Möglichkeiten abgedeckt werden, ist der weitergereichte Maschinen-Code immer recht generisch gehalten - Overhead!
Man kann in Excel-VBA auch WinAPI-Funktionen aufrufen, wenn man weis wie's geht. "GetTickCount" habe ich mir schon öfters geholt - zur Performance-Messung meiner Programm-Algorithmen. SQL-Strings senden und empfangen geht auch.
Ich habe sogar schon Audio-Files offline bearbeitet; das hat mit einer Tabellenkalkulation nichts mehr zu tun, geht aber trotzdem.Ob ich C++ MASSIV unterschätze, werde ich selbst sehen; aber ich sage jetzt ganz keck: Vielleicht unterschätzt du ja nur mich
Auf welche Technologie ich setzen soll? Das x86-Konzept wird uns noch länger erhalten bleiben - genau so wie in den Autos nach über 100 Jahren noch immer Kolbenmaschinen laufen, und noch immer neue Audio-CDs nach dem technischen Stand von 1983 produziert werden.
Ob aber die Metro-Overfläche von Windows 8 in Windows 9 oder 10 noch enthalten ist wage ich zu bezweifeln. Zum Glück gibt's "Classic-Shell"
-
Fletcher schrieb:
Auf meinem PC ist eine .NET-Anwendung installiert - es ist die "aquasuite" von Aqua-Computer - mein PC ist nämlich wassergekühlt. Beim Umschalten der verschiedenen "Masken" am Bildschirm hat man das Gefühl man blättert ein Buch um, weil es genau einen so kurzen Moment dauert bis der Bilschirmbereich neu gezeichnet worden ist. Sie verhält sich generell etwas träge.
Das sind Vorurteile, die durch paar schlechte Anwendungen bekräftigt werden. Ich habe jahre lang als C# Entwickler gearbeitet. Der Performanceunterschied ist meist kaum messbar und so gut wie nie spürbar, erst recht nicht bei so trivialen Sachen wie GUI. Und dir gehts ja nicht grad um HPC Computing. Vor allem bei verteilten Anwendungen würd ich eher .NET bevorzugen.
Ich würd einfach mal keck behaupten, du überschätzt dich selber
Aus dem was ich so rausgelesen habe, würd ich sagen, du kennst dich generell "recht gut aus", aber dir fehlt das Wissen und die Erfahrung, was Softwarearchitekturen angeht. SAP ist kein "einfaches Client/Server System" Man sollte schon deutlich mehr Ahnung von sowas haben, bevor man sowas angeht. Es kann schon gut sein, dass du irgendwann ein funktionierendes, vielleicht gut funktionierendes System auf die Beine bekommst, mit dem man auch eine Weile arbeiten kann. Aber aus der Sicht eines Softwareentwicklers wird es sehr wahrscheinlich keine wartbare/erweiterbare Basis haben. Irgendwann kommen immer neue Anforderungen, oder du bist irgendwann weg, und die Firma entschließt sich, das Projekt an extrene Softwareentwickler zu geben und die werden sich nur denken "WTF???".
Ich sage das nicht, um dich zu beleidigen oder zu entmutigen. Ich habe das einfach schon zu oft erlebt. Ohne die entsprechenden Kenntnisse und Erfahrung (und die hast du nicht, sonst würdest du so eine Frage nicht stellen, oder nicht in der Form stellen) lassen sich solche Anwendungen einfach nicht aus dem Boden stampfen. Alles was man sich selber irgendwie überlegt, funktioniert nur bis zu einem gewissen Grad. Danach führt es nur zu einer weiteren unwartbaren Lösung, die irgendwann teuer abgelöst werden muss. Ich musste schon in mehreren Firmen solche Projekte ablösen. Das mag sogar nach außen gut funktionieren, schließlich haben die Firmen damit jahrelang gearbeitet, aber intern ist es meist zum Haare raufen. Bevor du ein weiteres solches System anfängst, überleg dir lieber gut, ob du dich wirklich gut genug auskennst (und ich meine nicht "programmieren"), und ob dir eine Antwort in so einem Forum reicht.
-
Daß du meinst, ich kenne mich "recht gut aus", ist mir schon Lob genug
Das Wissen und die Erfahrung über Software-Architekturen fehlt mir sicher, denn ein Projekt in der Größe habe ich noch nie gemacht. Es sei bitte gesagt, daß ich alles was ich bisher gemacht habe, neben meiner eigentlichen Arbeit getan habe (schon während der Arbeitszeit aber eben neben der Hauptaufgabe, weil IT-Tätigkeiten in meinem Bereich gar nicht vorgesehen sind.)
Ich will mein "Projekt" ja gar nicht auf SAP-Level bringen, denn dazu würde ich gar nicht lang genug leben.
Sind die Möglichkeiten des Frontends aber zu stark eingeschränkt, entsteht der Wunsch der User nach mehr; Und wenn man nicht aufpasst ist die Synthax bald so komplex, daß man gleich ABAP von SAP nehmen hätte können.Allgemein: Wenn Programmänderungen so kompliziert werden, daß sie nicht mehr mit der Geschwindigkeit, der von außen erzwungenen Prozeßänderungen, mithalten können, muß man das bestehende System hinterfragen ob es so noch Sinn macht. Es besteht dann die Gefahr, daß der Mensch der Maschine dient und nicht umgekehrt. Heutzutage ist diese "Diener"-Umkehr recht oft anzutreffen; sie wird akzeptiert, weil eine Ersatzlösung zu teuer ist, nicht schnell genug verfügbar und auch sonst alles zusammenbrechen würde.
Betreffed der "unwartbaren Lösungen": Die werden immer entstehen. Glaubst Du das weder Deine, noch meine Lösungen im Jahr 2032 noch irgendwie zum Rest passen?
-
Zufällig sehe ich einen ganz anderen Thread hier im C++/MFC-Forum "VS2010, MFC Programme werden größer?"
Das ist genau das weshalb ich vorerst versuche ohne .NET, ATL und MFC auszukommen - weil hier immer "fremde" Komponenten zwischengeschaltet sind, über die ich keine Kontrolle habe!
Komponenten die bei einem Versionsupdate mein eigentliches Programm beeinträchtigen könnten, weil es jetzt Features gibt, die mit dem Rest des Programms nicht harmonieren..NET oder MFC würden mir viel Programmierarbeit abnehmen - weiß ich - aber vorerst strebe ich einmal nach Unabhängigkeit.
-
Fletcher schrieb:
Zufällig sehe ich einen ganz anderen Thread hier im C++/MFC-Forum "VS2010, MFC Programme werden größer?"
Das ist genau das weshalb ich vorerst versuche ohne .NET, ATL und MFC auszukommen - weil hier immer "fremde" Komponenten zwischengeschaltet sind, über die ich keine Kontrolle habe!
Dann wuerde ich aber auch keine C++ Library Sachen wie std::string oder std::cout verwenden. Und lieber garnicht erst die API deines Betriebssystems benutzen sondern besser ein eigenes Schreiben. Aber lieber nicht auf herkoemmlicher Hardware - besser du designest deine Hardware selbst. Ich wuerde mich dabei aber nicht auf die herkoemmliche Forschung verlassen sondern lieber das mit den Transistoren nochmal ueberdenken ob da nicht was besseres geht.
Dann kannst du in dem Zug auch gleich eigenen Storm produzieren damit die Spannung perfekt zu deiner neuen Hardware passt und du nicht umwandeln musst und wer weiss schon was da fuer Schrott im Stromnetzwerk drinnen ist - lieber unabhaengig sein.
-
Du mußt meine Haltung natürlich gleich übertreiben
C/C++, gerne mit Standardlibrary , und WinAPI sind schon die Grundbausteine.Ich wuerde mich dabei aber nicht auf die herkoemmliche Forschung verlassen sondern lieber das mit den Transistoren nochmal ueberdenken ob da nicht was besseres geht.
Du wirst lachen, das tun andere bereits: Schau einmal bei Wikipedia unter "Graphen". Bei Silizium ist praktisch bei 5 GHz Taktfrequenz schluß, mit den Graphen werden 500 GHz und mehr möglich sein.....
Evolution der Schaltelemente: Relais, Röhre, Transistor, Graphen.
Apropos Relais: Der (Konrad) Zuse Z3 Relaisrechner wurde vom Sohn des Erbauers mit modernen Relais nachgebaut - schau auf Youtube. Ich finde dieses Projekt insofern interessant und sinnvoll, daß man sich einmal wieder darauf besinnen sollte, wofür jeder einzelne Schalter im Prozessor gut ist - Stichwort: "Rechenwerke". Es wird ja hoffentlich keiner behaupten, daß ein Programmierer 1,4 Milliarden Transistoren in einem Core-i5 voll unter Kontrolle hat.
Bei .NET und Java wird ganz offen gesagt, daß der interne Programmoverhead durch die Rechenleistung heutiger Prozessoren kompensiert wird. Dafür bekommt man recht schnell eine Anwendung fertig.
-
Fletcher schrieb:
Bei .NET und Java wird ganz offen gesagt, daß der interne Programmoverhead durch die Rechenleistung heutiger Prozessoren kompensiert wird. Dafür bekommt man recht schnell eine Anwendung fertig.
Du hast einfach eine falsche Vorstellung von Softwarearchitektur
-
@Fletcher
Du hast eine vollkommen falsche Vorstellung von .NET. Was du schreibst ist völliger Quatsch. Der Schluss von einem .NET Programm auf .NET im Allgemeinen entbehrt jeglicher Logik. Der Vergleich VBA <-> C# ist auch reichlich lächerlich. Und ich garantiere dir dass du die Komplexität der Sache unterschätzt.Was Softwarearchitektur angeht: wenn man das kann, dann kann man durchaus auch recht komplexe Software so bauen dass Änderungen leicht möglich sind. Und wenn man es nicht kann, dann braucht es keine 30 oder 100 Jahre bis man vor einem völlig unwartbaren Haufen steht. Je nachdem wie schlecht man wirklich ist, und wie oft man Änderungen vornimmt kann man das in ein paar Wochen hinbekommen.
Aber OK, nachdem du vollkommen beratungsresistent bist und nur das bestätigt bekommen wolltest was du sowieso schon vor hattest: ja, lern C++ und schreib ne Anwendung die direkt auf den SQL-Server hingreift. Ist ne richtig gute Idee
-
OK Leute, mag sein daß ich von Softwarearchitektur nicht viel verstehe; ich weiß aber ganz genau wie das Endprodukt aussehen soll und wie es performen soll. Schaffe ich es nicht die Anwendung so zu erstellen, daß sie nach meinem Begriff gut performed, muß ich das ohnehin mit mir selbst ausmachen.
Ich habe nie behauptet daß mein Vorhaben zwischen 2 Tassen Kaffee erledigt werden kann. Ich habe auch nie gesagt, daß die Combo C++ und SQL-Server das gelbe vom Ei ist. Ich wollte einfach Meinungen dazu hören, und ich habe sie gehört. Die Bringschuld liegt jetzt bei mir, damit zu Beginnen und eventuell an dieser Stelle über erste Ergebnisse zu berichten - was aber viele Wochen dauern kann, weil --> Freizeitprojekt neben einem Nicht-IT-Fulltimejob.
Das schöne an der IT ist, daß von Anfang an absolute Gleichberechtigung herrscht: Während man bei vielen Berufen eine höhere Ausbildung oder gar ein Studium vorweisen muß, spricht es für sich wenn es 14-Jährige gibt die in den Pentagon-Computer eindringen können (nur ein symbolisches Beispiel). Der 14-Jährige hat per sofort bewiesen, daß er über stark überdurchschnittliche Computerkenntnisse verfügen muß.
Ich erinnere nocheinmal an mein 1.Posting in diesem Thread: Eine 70er-Jahre Kiste mit Terminal-Emulatoren bringt angeforderte Daten in weniger als 0,3s auf den Bildschirm, während heutige Plattformen schon 0,3s brauchen damit sie das "Loading"-PopUp mit dem drehenden Kreis anzeigen?!?! Hier stimmt doch etwas nicht!
-
Fletcher schrieb:
OK Leute, mag sein daß ich von Softwarearchitektur nicht viel verstehe; ich weiß aber ganz genau wie das Endprodukt aussehen soll und wie es performen soll. Schaffe ich es nicht die Anwendung so zu erstellen, daß sie nach meinem Begriff gut performed, muß ich das ohnehin mit mir selbst ausmachen.
Nur weil ich weiss wie eine Rakete aussieht, bin ich noch lange kein Raktentechniker.
Ich erinnere nocheinmal an mein 1.Posting in diesem Thread: Eine 70er-Jahre Kiste mit Terminal-Emulatoren bringt angeforderte Daten in weniger als 0,3s auf den Bildschirm, während heutige Plattformen schon 0,3s brauchen damit sie das "Loading"-PopUp mit dem drehenden Kreis anzeigen?!?! Hier stimmt doch etwas nicht!
Solche Aussagen machen mich sprachlos und lassen mich an der Menschheit zweifeln.
-
Was genau bitte macht dich an meiner Aussage sprachlos? Ich glaube ich habe es genau auf den Punkt gebracht worum es mir geht.
Aber nocheinmal anders gefragt: "Wieso ist ein 70er-Jahre System schneller als eines aus den 2010er Jahren?"Hier geht es gar nicht um C++, .NET, Java oder sonst was - völlig uninteressant in dem Fall! Der Laie sieht nur, daß das neue System langsamer antwortet...
Die Programmiersprache bei unserem Uraltsystem war übrigens COBOL!
-
Fletcher schrieb:
[...] Anwendung [...] erstellen [...]
Dann gehe hin, und erstelle mal.
-
Fletcher schrieb:
"Wieso ist ein 70er-Jahre System schneller als eines aus den 2010er Jahren?"
Ist es nicht.
-
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.
Ja nachdem was am alten System zu tun war, konnten unsere Power-User bis zu 3 Inputs (Transmits) pro Sekunde (!) per Hand einegeben.Unsere IT hat immerhin zu keiner Zeit behauptet, daß das neue System besser sei; man war gezwungen auf ein neues System umzustellen, weil die alten Programmierer (COBOL) in Pension gehen und niemand mehr da ist, der COBOL kann.
Selbst wenn jemand COBOL könnte, hätte er es beim Gesamtsystem mit 1 Mio Code-Zeilen zu tun gehabt - in Form von Spaghetti-Code und ohne Dokumentation. (Info vom Abteilungsleiter dort, der selbst noch in die Schule ging, als man begann das System zu programmieren).
Trotz dieser beiden No-Go's war man in der Lage das System mehrere Jahrzehnte am Laufen zu halten.Was hat man eigentlich in den 90ern verwendet wenn man über eine Windows-Oberfläche in eine SQL-Datenbank hineinwollte? Da kannst Du einige Sub-Foren hier streichen weil manche Dinge damals gar nicht gab!
-
Fletcher schrieb:
Die Bringschuld liegt jetzt bei mir, damit zu Beginnen und eventuell an dieser Stelle über erste Ergebnisse zu berichten - was aber viele Wochen dauern kann
Das ist ja gar nicht das Problem... Ich bin mir sogar ziemlich sicher, dass die ersten Ergebnisse kommen und du was halbwegs lauffähiges hinbekommst. Ich würde sogar behaupten, je weniger man sich auskennt, desto schneller kommt man voran
Die Probleme kommen aber später, wenn es darum geht, aus dem Prototypen ein Produkt zu machen (damit mein ich nicht unbedingt etwas, was man verkaufen kann, reicht auch etwas, was man guten Gewissens intern einsetzen und dann auch anpassen/erweitern kann).
Als ich angefangen habe zu programmieren (nur programmieren und noch keine Ahnung von Softwareentwicklung hatte), habe ich jahrelang an einem Animationsprogramm gearbeitet. Und es konnte erstaunlich viel. Es lief überhaupt nicht sauber, aber es waren sehr viele fortgeschrittene Features drin. Das Problem war, dass es reinster Spaghetticode war, aus dem ich niemals ein Produkt hätte machen können. Das habe ich aber auch erst Jahre später verstanden. Heute wär ich nicht mehr in der Lage, ansatzweise so weit zu kommen, wie damals. Allein, weil ich wahrscheinlich Jahre für die Planung gebraucht hätte. Damals habe ich einfach direkt angefangen und alles was ich mir vorgestellt habe dann auch möglichst direkt implementiert. Und dann sind die ganze Zeit immer mehr Abhängigkeiten und Sondefälle reingekommen, die sich überall durchgezogen haben, aber ich habs eine Weile im Griff gehabt. Sowas könnte ich heute gar nicht mehr machen. Allein bei den grundlegenden Klassen könnte ich nicht einfach anfangen, ohne ein Gesamtkonzept zu haben, auf dem alle Features aufbauen. Und wenn ich soweit wäre, würde ich allein für die Basis (wo man noch gar nichts sieht oder ausprobieren kann) viel länger brauchen, als ich damals für das ganze Programm gebraucht habe, wo man schon viel sehen konnte. Und da ich das schon weiß, würde ich so ein Programm nicht mehr anfangen
Bei deinem Client-Server System verhält es sich ähnlich. Natürlich kann man einfach mal anfangen und irgendwas funktionierendes hinbekommen. Aber du wirst sicherlich über tausend Stellen stolpern, wo sich schon Entwickler vor dir Gedanken gemacht haben und wahrscheinlich bessere Lösungen gefunden haben, als du. Und du wirst sehr wahrscheinlich immer wieder über irgendwas stolpern, was nicht in dein Konzept passt, und du wirst es deswegen umbauen müssen. Deswegen halte ich es für wenig erfolgversprechend, ohne die entsprechenden Kenntnisse und Erfahrung einfach mal mit so einem Projekt anzufangen. Auf lange Sicht wird es ziemlich sicher nichts...Fletcher schrieb:
Das schöne an der IT ist, daß von Anfang an absolute Gleichberechtigung herrscht: Während man bei vielen Berufen eine höhere Ausbildung oder gar ein Studium vorweisen muß, spricht es für sich wenn es 14-Jährige gibt die in den Pentagon-Computer eindringen können (nur ein symbolisches Beispiel). Der 14-Jährige hat per sofort bewiesen, daß er über stark überdurchschnittliche Computerkenntnisse verfügen muß.
So hab ich vor 15 Jahren auch gedacht... Erstens, vergiss die Märchen, wo irgendwelche 14 jährigen Genies irgendwas hacken. Und zweitens würde ich niemanden einstellen, der kein Studium vorweisen kann. Ja, es gibt Leute, die ohne Studium ganz brauchbar programmieren können (und es gibt welche mit Studium, die es überhaupt nicht können). Aber die sind meist noch sehr sehr weit davon entfernt, gute Entwickler zu sein. Ausnahmen sind vielleicht studierte Mathematiker und Physiker mit entsprechender Erfahrung. Aber sicher keine 14 jährigen Schüler oder irgendwelche Amateure, die daheim neben dem Beruf programmieren gelernt haben. Als ich Schüler war, habe ich meine Fähigkeiten als Entwickler auch sehr stark überschätzt. Programmieren können und viele spezielle Kenntnisse zu haben reicht noch bei weitem nicht.
-
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.
