Whiz-zarD

Sehe ich genauso. Deswegen schaue ich mir solche Stellenangebote auch nicht mehr weiter an. Allein wenn ich nur die Stellenanzeige anschaue: Da muss ich nur mit dem Kopf schütteln, dann das ist eine allgemeine Beschreibung, was ein Entwickler überhaupt macht. Da steckt überhaupt keine Information, was eigentlich gewünscht wird. Genauso gut könnte man diesen Satz auch weglassen. Nicht einmal der Technologie-Stack wird hier klar. Handelt es sich hier nun um eine Desktop Applikation und man arbeitet vielleicht mit Swing oder ist es eine Smartphone-App und arbeitet mit Android oder ist es sogar eine Web-App und arbeitet mit React/Angular/Was-auch-immer? Sucht man überhaupt einen Frontend-Entwickler oder eher jemanden im Backend-Bereich oder sucht man einen Allrounder? Auf was lässt man sich da also ein? Weiterhin steht dort u.a. Ja, welche denn? MSSQL, OracleDB, MySQL, MariaDB, ... ? Oder geht es hier um DB2, weil Erfahrung im IBM-Umfeld vom Vorteil wäre? Bin ich, der hauptsächlich im OracleDB-Umfeld arbeitet, der richtige? Und nein, relationale Datenbank ist nicht gleich relationale Datenbank. Es gibt da einen schönen Spruch: "Der Knochen kommt nicht zum Hund" oder "Seit wann kommt der Knochen zum Hund?" Wieso sollte ich mich also auf so eine Stelle bewerben? Eine Firma sucht Mitarbeiter. Also sollte doch die Firma erstmal in Vorleistung gehen und sich präsentieren.

EVA ... Oha! Den Begriff habe ich bestimmt schon seit 15 Jahren nicht mehr gehört. Ich wusste gar nicht, dass dieser überhaupt noch Verwendung findet ^^" Allerdings verstehe ich nicht, wie man nicht danach programmieren sollte. Das ist das Grundprinzip von Datenverarbeitung und findet eigentlich immer statt. Man bekommt ein Input, es wird verarbeitet und gibt etwas aus. Das EVA-Prinzip ist ja nicht mal auf die IT beschränkt, sondern gilt allgemein. So verläuft auch ein Gespräch unter zwei Menschen nach diesem Prinzip: Man bekommt Input (hört zu, was der andere sagt), verarbeitet es (zieht Rückschlüsse aus dem Gesagten) und gibt dann eine Ausgabe (man erwidert etwas). Wenn du also eine Methode in Java geschrieben hast, die ein Parameter entgegennimmt und ein Rückgabewert besitzt, ist das schon EVA. Als ich mit dem Programmieren anfing, da gabs noch kein Internet. Da gabs Zeitschriften und Bücher mit seitenlangen Code zum Abtippen. In einer Firma, wo ich mal gearbeitet habe, war der Code voll von StackOverflow-Snippets. Der Code war voll von Kommentaren, in denen StackOverflow-Links standen. Ich persönlich halte mich da sehr zurück. Ich suche zwar auch oft nach Lösungen von bestimmten Problemen aber ich nehme den Code nur als Inspiration, wie man die Probleme lösen könnte und versuche dann ein Code zu schreiben, der auch zu meinem Stil passt. Oftmals sind es aber eh nur Lösungen von trivialen Problemen, nach denen ich suche um eine elegante Lösung zu finden. StackOverflow dient für mich eher als Wissensdatenbank, um mal tiefer unter die Haube gucken zu können, um zu verstehen, was da eigentlich mit dem Code passiert.

Ehrlich gesagt: Nein. Bis jetzt habe ich nur schlechte Erfahrung mit solchen Beratern gemacht und solche Stellenangebote schaue ich mir auch erst gar nicht mehr an. Ich verstehe die Diskretion aber ein Bewerber hat ja auch ein Anrecht zu erfahren, auf was er sich da einlässt, denn auch er geht ein Risiko ein. Vielleicht ist der Job ja auch gar nichts für ihn. Bei einigen Beratern hatte ich erst die Firma in Erfahrung bringen können, wenn ich den Vertrag unterschrieben hätte. Es hieß nur "eine Firma in Hamburg". Hamburg ist nicht gerade klein und das kann sehr wohl auch Probleme bereiten, wenn die Firma am anderen Ende von Hamburg ist und ich erst mal zwei Stunden da hinfahren muss. Nee Danke. Da ist meine Zeit zu kostbar, um diese mit Beratern zu verschwenden.

Es ist überhaupt nicht mal klar, welches DBMS er/sie verwendet...

Bis auf die Leseprobe habe ich von diesem Buch noch nichts gelesen aber das, was ich gelesen habe, sieht gut aus.

Mit einem Taschenrechner oder einer grafischen Oberfläche würde ich nicht anfangen. Ein Taschenrechner ist weitaus komplexer, als man es sich vorstellt. Die Tutorials, die ich darüber gesehen habe, produzieren alles andere. Nur keinen brauchbaren Taschenrechner. Um einen brauchbaren Taschenrechner zu bauen, braucht man schon mehr Kenntnisse und zwar nicht nur, was die Sprache anbelangt, sondern auch Kenntnisse darüber, wie man sowas geschickt entwickelt. Diesbezüglich hat sich z.B. die sog. Polnische Notation sehr gut bewehrt und wird auch in herkömmlichen Taschenrechnern verwendet. Daraus wird dann später ein endlicher Automat erstellt, die dann die Rechenaufgabe abbildet und durchführt. Die ganzen Taschenrechner-Tutorials zeigen schön, wie man eigentlich Code nicht schreiben sollte. Es ist immer ein Wüst an kopierten Code und die Logik liegt immer in den Klassen der Oberfläche, anstatt in einem eigenen Projekt. Fange auch lieber mit einem Kommandozeilen-Tool an. Bei einer grafischen Oberfläche passiert im Hintergrund zu viel Magie, die ein Anfänger nicht versteht. Z.B. wie überhaupt die Events auslöst werden, denn das passiert nicht von Geisterhand. Zum Glück nicht, nein.

Was willst du überhaupt erreichen?

Google mal nach "Raiders". Erweitert dein Horizont ...

Darf ein Mensch jetzt kein Hobby mehr haben und dies im Internet zeigen, weil ein potenzieller, zukünftiger Arbeitgeber nach dieser Person auf Facebook suchen könnte und herausfindet, dass die Person Hobbies hat, die er nicht versteht? ... Sorry aber Privat ist Privat und Arbeit ist Arbeit. Wenn ein Arbeitgeber meint, er hat Vorurteile gegenüber anderen Menschen, weil ihm ein Profilbild nicht passt, weil er es nicht kapiert und auch keine Lust hat hat, zu recherchieren, dann ist er wohl auch nicht der richtige Arbeitgeber und von solchen Firmen sollte man dann auch einen großen Bogen machen. Sorry, aber jeder der mal was von American Football und NFL gehört hat, kann was mit dem Begriff "Raiders" anfangen. Gemeint ist die Mannschaft Oakland Raiders. Ein Blick unter Google verrät auch, dass "Raiders Nation" die Fans dieser Mannschaft betitelt. Dazu gibt es sogar einen Wikipedia-Eintrag. Also bitte einmal das Gehirn einschalten ...

Was heißt "nur nach Vorgabe"? Wird einem "Codeäffchen" mitgeteilt, welche Tasten er drücken soll? Ein Entwickler muss immer irgendwelche Entscheidungen treffen. Er ist für den Code verantwortlich. Wie man da keine Entscheidungen treffen muss, ist mir ein Rätsel.

Das Wort "Codeäffchen" lese ich öfters und frage mich jedes Mal, was das bittesehr sein soll? Offenbar entstammt das Wort vom Infinite-Monkey-Theorem. Dabei frage ich mich immer, was das nun mit Softwareentwicklung zu tun hat? Vielleicht gibt es Buden, die solange auf der Tastatur rumhacken, bis irgendwann mal eine Software dabei rauskommt aber wenn eine Firma ernsthaft Geld mit ihrer Software verdienen möchte, dann ist es schnell vorbei mit dem "Codeäffchen". Softwareentwicklung ist nun mal mehr, als nur Code zu schreiben. Heutzutage haben wir es mit einem gigantischen Technologiestack zu tun, der irgendwie orchestriert werden muss. Mit ein paar "Codeäffchen" kommt man da nicht weit und wenn eine Firma auch auf wartbaren Code achten möchte, dann müssen auch Entwickler ran, wie was von Clean Code verstehen. Darüber hinaus ist auch sehr viel Kommunikation von Nöten. Also die sog. "Soft Skills" sind heutzutage auch sehr wichtig geworden. Glaube mir mal, so weit weg von "state of the art" ist das nicht. Mag sein, dass Startup-Hipster andere Technologien verwenden, aber ist würde davon mal ausgehen, dass viele Firmen sowas wie Hibernate, Spring MVC oder Bootstrap gar nicht kennen. Man darf sich auch nicht von den Stellenangeboten verunsichern lassen. Oftmals spielen sie da Bullshit-Bingo und feuern alles ab, was denen so einfällt. Die Realität sieht dann meist anders aus. Bewirb dich einfach auf Junior-Entwickler-Stellen. Du wirst sehen, dass andere auch nur mit Wasser kochen und auch nicht wirklich viel schlauer sind, als du selbst. Die Erfahrung kommt erst mit den Jahren. Also mache dir da mal keine Sorgen.

Indem man eine Versionsverwaltung verwendet. Sharepoint hat sowas integriert: Aktivieren und Konfigurieren der Versionsverwaltung für eine SharePoint-Bibliothek

Ich würde dennoch dafür sorgen, dass die Datei über eine Versionsverwaltung verwaltet wird, damit man Änderungen zu jeder Zeit nachvollziehen und rückgängig machen kann.

Ist das wirklich so sinnvoll? Wäre eine Web-Applikation nicht sinnvoller? Ich mein, der hiesige Rollout-Prozess würdest du dort minimieren. An Tankstellen arbeiten ja auch nicht gerade IT-Spezialisten. Die haben wohlmöglich keine Ahnung, wie man eine Software installiert. Das nächste ist ja, wie sicherst du, dass alle die aktuelle Version installiert haben? Die Software wird ja nicht überall zur selben Zeit aktualisiert. Dann musst du schon auf eine Versionierung der Schnittstellen achten. (Stichwort wäre z.B. Semantic Versioning) Bei einer Web-Applikation könnte man das Ganze sehr minimieren, weil du dann nur die neue Applikation auf dem Server ausrollen müsstest und jeder hat automatisch die neue Version. Man braucht dann auch kein Java installieren, sondern es reicht einfach nur ein Web-Browser. In anbetracht dessen, dass immer mehr Smartphones und Tablets im Einsatz sind, kann man sich auch vorstellen, dass eine Tankstelle überhaupt kein PC besitzt. Was dann? Auch hat nicht jede Tankstelle direkt neben der Kasse ein PC. Der müsste erst mal angeschafft und installiert werden. Ein Tablet neben die Kasse zu legen, wäre viel einfacher. Auf Java zu setzen, weil man Plattformunabhängig sein möchte, ist heutzutage ein falscher weg, denn Java ist nicht plattformunabhängig. Es läuft auf Windows und Linux ja aber nicht auf iOS, Android. Eine bessere Abdeckung der Plattformunabhängigkeit erreicht man mit Web-Applikationen, da auf jedem gängigen Betriebssystem ein Browser existiert.

Ja, Bildung ist Ländersache. Keine Ahnung, wie es heutzutage in Schleswig-Holstein aussieht, aber damals war das noch Stoff in der 7. Klasse einer Realschule. Man hat es den Schülern aber nicht intensiv beigebracht, sondern nur mal eben schnell angerissen, dass es neben dem Dezimalzahlensystem auch noch weitere Zahlensysteme gibt und wie man von einem System zum anderen umrechnen kann. Das Thema war dann binnen weniger Tage durch.

Sowas hatte ich in der 7. Klasse auf einer Realschule. Gut, das ist jetzt aber auch schon 20 Jahre her.

Dazu fällt mir noch ein: Welche Alternative gibt es zu POP3 und ist die Alternative nicht sinnvoller?

Und was meinst du, wie man eine Datei blockweise einliest? Eine Textdatei zeilenweise einzulesen ist doch schon quasi blockweise. Eine Zeile repräsentiert dann ein Block.

Wenn man es genau betrachtet, ist gar nichts richtig. Strukturierte Programmierung führt nicht zwangsläufig zu übersichtlichen und änderungsfreundlichen Programmen. Es gibt weitere Paradigmen, die zur Gattung der strukturierten Programmierung zählen. Es erspart nicht das Testen der Logik. (Stichwort Unittests) Einfügen von Kommentaren wird nicht verboten Es erleichtert auch nicht die Fehlersuche. Schon mal der Compiler formal eh keine Fehler sucht. Außer Syntaxfehler. Ich nehme aber mal an, dass Nummer 1 richtig sein soll, weil man damit Programm strukturiert aufbauen kann. Die Betonung liegt wohlgemerkt auf kann. Eine strukturierte Programmierung legt erst mal keine Regeln fest, wie entwickelt werden muss bzw. soll. Das liegt in der Disziplin der Entwickler selbst. Man kann auch mit einer Objektorientierten Sprache kompletten Murks bauen. So habe ich schon Klassen gesehen, die über 15.000 Zeilen besitzen oder Methoden, die eine zyklomatische Komplexität von über 1.000 besitzen oder Methoden, die über 10 ref-Parametern besitzen. All dies führt nicht zu einem übersichtlichen und änderungsfreundlichen Code. Darum gibt es ja Tools, die einen Entwickler dazu zwingen, strukturell sauberen Code zu schreiben. z.B. StyleCop. Der Compiler von der Sprache Go hat schon so ein Tool integriert. So ist es z.B. nicht möglich, sein Code zu kompilieren, wenn man eine Variable definiert hat aber nirgends verwendet.

Tableau QlikSense bzw. QlikView JasperReports MicroStrategy

Ein Interface ist, wie der Name schon sagt, eine Schnittstelle. Mit Interfaces definiert man die Methodenköpfe, die eine Klasse implementiert. Über Schnittstellen lassen sich verschiedenartige Implementationen über die selbe Schnittstelle realisieren, ohne dass der Aufrufer gar nicht wissen muss, um welche konkrete Klasse es sich handelt. Wir hatten ja schon mal das IDisposable, was ebenfalls ein Interface ist. Das Interface besitzt lediglich nur die Methode Dispose(). Viele Klassen implementieren diese Schnittstelle. Ein anderes Beispiel wäre das IEnumerable<T>-Interface, was u.a. von Arrays und Listen implementiert wird und einen Enumerator zur Verfügung stellt und mit dem Enumerator haben wir dann die Möglichkeit, mit der foreach-Schleife über die Elemente zu iterieren. In meinem Beispiel habe ich nun ein Interface erstellt, was einen sehr simplen Logger darstellt. Über den Konstruktor vom CsvChanger reiche ich dann ein Objekt rein, was dieses Interface implementiert. Der CsvChanger weiß dann, dass dieses Objekt die Methode Log() besitzt und ruft diese Methode auf, Ansonsten weiß es gar nichts über dieses Objekt. Der CsvChanger ist somit unabhängig vom Logger, weil dieser Logger jetzt irgendeiner sein kann, der dieses Interface implementiert. Es kann, wie in meinem Beispiel, ein Logger sein, der die Logeinträge auf die Konsole loggt, oder in die Datenbank, als Datei oder E-Mail etc. Vielfach liest man auch, dass Interfaces für Mehrfachvererbung gedacht sind aber das ist nicht richtig und ich würde auch von dieser Meinung Abstand halten. Wer Mehrfachvererbung braucht, der macht schon was falsch. Ich bin noch nie in eine Situation gekommen, wo ich mir gewünscht hätte, C# oder Java könnte echte Mehrfachvererbung, wie es bei C++ der Fall ist. Mehrfachvererbung hat für mich den Charakter, dass eine Klasse zu viel macht.

Doch, genau das ist der Sinn der Sache. Man will ja in unterschiedlichen "Umgebungen" auf Fehler unterschiedlich reagieren. z.B. will man in einer Konsolenanwendung die Fehlermeldung auf der Konsole ausgeben oder bei einer Desktop-Anwendung mit grafischer Oberfläche eine MessageBox oder bei einer Webanwendung irgendwo als Hinweis-Text. Du hast aber die Exceptions schon in der CsvChanger-Klasse abgefangen und festgelegt, dass die Fehlermeldung auf der Konsole ausgegeben werden soll, was aber zur Folge hat, dass der Nutzer einer Desktop- oder Web-Anwendung gar nicht die Fehler mitbekommt. Vielleicht möchte man auch, dass der Nutzer entscheiden kann, im Falle eines Fehlers. z.B. du änderst Tausend CSV-Dateien und eine schlägt fehl. Man möchte vielleicht dem Nutzer die Möglichkeit bieten, die Aktion abzubrechen oder den Fehler zu ignorieren und weitermachen. Daher würde ich die ganzen Try-Catch-Blöcke weglassen und der Aufrufer soll die Fehler behandeln. Hier würden wir in den Bereich der sog. Dependency Injection kommen, denn in eine Datei zu loggen ist ja nicht die einzige Art des Loggings. Ein Logging kann auch auf der Konsole geschehen oder in eine Datenbank, als E-Mail, in eine Textbox einer grafischen Oberfläche, etc. Da sind also keine Grenzen gesetzt. Ein Benutzer einer Web-Anwendung hat durchaus ja keinen Zugriff auf eine Log-Datei. Anstatt also dass wir vorgeben, dass wir eine Datei schreiben, reichen wir als Abhängigkeit (engl: dependency) einen Logger in die Klasse über den Konstruktor rein. Dafür entwickelt man ein Interface und eine konkrete Implementierung und man arbeitet später dann nur noch mit dem Interface. Hier mal ein einfaches Beispiel für einen Logger: Das Interface: public interface ILogger { void Log(string message) } Eine konkrete Implementierung, die auf der Konsole loggt: public class ConsoleLogger : ILogger { public void Log(string message) { Console.WriteLine(message); } } Die Klasse CsvChanger: public class CsvChanger { private ILogger logger; public CsvChanger(ILogger logger) { this.logger = logger; } ... } Hier sieht man jetzt, dass ein Objekt in die Klasse als Abhängigkeit reingereicht wird, die das Interface ILogger implementiert. In der Main-Methode erzeugst du die Objekte, die der CsvChanger benötigt: public static void Main(string[] args) { ... ILogger logger = new ConsoleLogger(); CsvChanger changer = new CsvChanger(logger); ... } Später, bei der Verwendung vom Logger in der CsvChanger-Klasse schreibst du dann einfach folgenden Code: logger.Log("Das ist ein Text"); Jetzt ist die Klasse CsvChanger vom Logger unabhängig. Anstatt einen Konsolen-Logger kannst du jetzt nun auch einen Logger schreiben, der in eine Datei loggt und diesen dort reinreichen. Der Klasse ist das nun egal, da sie vom Logger nur das Interface kennt aber nicht die konkrete Implementierung. Ich glaube, du hast es nun zu wortwörtlich genommen. Ja, eine Methode soll nur eine Aufgabe erledigt. Die Aufgabe wird aber durch den Methodennamen beschrieben. Wenn die Methode ChangeFile() heißt, dann kann die Methode sehr wohl die Datei lesen, ändern und speichern, weil der Methodenname genau dies ausdrückt: Die Methode soll eine Datei ändern. Sie soll aber neben dieser Aufgabe nichts anderes machen. Die Methode ChangeFile() wird dann intern in weitere Teilaufgaben unterteilt. Nämlich Lesen, Ändern und Speichern. Der Aufrufer von ChageFile() bekommt aber davon nichts mit. Dieses Thema hat aber eigentlich nichts mehr mit Objektorientierung zu tun, sondern mit Clean Code. Natürlich kann man ChangeFile() auch wie ein Spaghetticode implementieren aber das ist nicht wirklich lesbar und vorallem nicht wartbar. Ein Entwickler verbringt mehr Zeit mit Code lesen anstatt mit Code schreiben und daher sollte der Code so lesbar wie möglich sein. Wenn die Methode ChangeFile() lediglich nur aus drei Zeilen Code besteht, dann versteht man die Arbeitsweise der Methode besser als wenn sie aus 100 Zeilen bestehen würde. Wer dann genauer in einen der drei Arbeitsschritte abtauchen muss, der schaut sich dann die Implementierung der jeweiligen Methode an, usw.

Warum so eine veraltete Technik (Win Forms)? Warum nicht eine Web-Anwendung? Und warum wird gefühlt bei jedem Projektantrag erwähnt, dass es eine MySQL-Datenbank sei. Die Datenbank sollte egal sein. Bei solchen Formulierungen habe ich immer das Gefühl, dass man die Datenbank nicht mittels einem O/R-Maper abstrahiert, sondern stumpf SQL-Queries schreibt und sie zur Datenbank schickt.

In der Klasse SettingsLoader fällt auf, dass du filename als private Member definiert hast, aber das brauchst du gar nicht. Also könntest du diesen auch löschen. iniText hat auch in Settings nichts zu suchen. Außerdem macht die Load()-Methode eigentlich noch zu viel. Schauen wir uns doch mal an, was sie macht: Sie liest die Ini-Datei ein Sie ermittelt Source Sie ermittelt Destination Sie gibt Settings zurück Das sind quasi vier Aufgaben und die ersten drei davon könnte man in separate Methoden packen, um den Code genauso lesbar zu machen, wie meine Aufzählung: class SettingsLoader { string iniText; public Settings Load(string filename) { this.iniText = this.ReadFile(filename); return new Settings { Source = this.GetSourceFromIniText(); Destination = this.GetDestinationFromIniText(); } } ... } Die Implementierungen der Methoden kannst du mal versuchen. Hierbei kannst du ja auch mal versuchen, das DRY-Prinzip (Don't Repeat Yourself) einzuhalten. Vielleicht fällt dir ja auf, dass das Lesen von Source und Destination quasi die selbe Aufgabe ist. Lediglich nur der reguläre Ausdruck ändert sich. Außerdem fällt in der Klasse CsvChanger auf, dass du zu viele Try-Catch-Blöcke drinnen hast. Die Catch-Blöcke geben auch immer was auf der Console aus. Damit ist die Klasse von Console abhängig. Für den Anfang kannst du es ja auch so lassen aber stelle dir mal die Frage, ob das so gut ist bzw. warum das nicht so gut sein könnte? Die Klasse CsvChanger würde auch einfacher zu lesen sein, wenn sie nur eine Datei bearbeiten würde. In der Hauptmethode könnte man ja die Dateien ermitteln und mittels einer Schleife iterieren und jedes Mal den CsvChanger aufrufen. Damit verlagert man die Logik weiter zum Aufrufer und die Klasse wird dadurch kompakter. Außerdem sehe ich, dass du dir mit Arrays ganz schön einen abbrichst. Informiere dir mal ein bisschen über Generics und dann über die Klasse List<T>. Ich verwende Arrays nur, wenn ich schon zur Entwicklungszeit exakt weiß, wie viele Elemente ein Array braucht. z.B. ein Schachbrett: Es hat immer 8x8 bzw. 64 Felder und das wird sich auch in hundert Jahren nicht ändern. Eine Anzahl von Dateien in einem Ordner kann sich sekündlich ändern und daher ist ein Array vielleicht nicht die beste Wahl. Außerdem schaue dir mal die foreach-Schleife an. Dann wirst du auch die hässlichen for-Schleifen los.

Das ist auch nur Teilweise richtig. Es ist zwar schon richtig, dass eine Sprache nur das Werkzeug ist aber auch das Werkzeug muss gut gewählt werden. Einen Nagel haut man ja auch nicht mit einem Schraubendreher in die Wand, sondern mit einem Hammer. Die Sprache muss also auch Frameworks besitzen, um das gewollte umsetzen zu können. Jemand, der eine Android-App schreiben möchte, wird also nicht C oder C++ dafür nehmen, sondern Java in Verbindung mit dem Android-SDK oder C# in Verbindung mit Xamarin. Allerdings sind die genannten Bedingungen von @Ronon Dex zu sehr allgemein, sodass man hier quasi jede gängige Sprache für nehmen könnte.