Whiz-zarD

In Hinblick dessen wäre auch die Dotcom-Blase zu erwähnen. Der Fachinformatiker entstand während der Boom-Phase. https://de.wikipedia.org/wiki/Dotcom-Blase

Ich würde schauen, welche Technologien und Programmiersprachen der Betrieb verwendet und dann gezielt nach Büchern suchen, sofern der Betrieb nicht schon welche besitzt. Alles andere macht aus meiner Sicht wenig Sinn.

Richtig. Was macht denn eine if-else-Abfrage? http://www.if-schleife.de

Und so sieht dann auch die Software aus... Ich höre immer wieder von Firmen, die versuchen ein großes Projekt mit Studenten aufzubauen. Zuerst klappt es auch wunderbar. Die Software nimmt schnell Form an und die Kunden sind zufrieden aber dann kommt die Nüchternheit: In jeder neuen Version gibt es immer mehr Bugs und die Releasezyklen werden immer länger... Unittests? Integrationstests? Gibt es nicht. Clean Code? Codemetriken? Was ist das? SOLID? DRY? Datenkapselung? Nie gehört.

http://php.net/manual/de/language.types.array.php Arrays in PHP sind eine Liste von Schlüssel-Wert-Paaren. Der Pfeil bedeutet, dass der Schlüssel einem Wert referenziert. Wenn du $wochentage["Sun"] eingibst, erhälst du "Sonntag", weil der Schlüssel "Sun" den Wert "Sonntag" referenziert.

Das Frage ich mich auch.

Glaub mir, wenn du einen richtigen Taschenrechner programmierst, bist du schon einige Zeit damit beschäftigt

Was für ein Quatsch... Wie soll man da auch großartig helfen können? Wir kennen diese Person nicht persönlich und auch nicht seine Neigungen. Auch für Freunde und Familie wird es schwer, die Frage zu beantworten. Das muss er wohl oder übel selbst mit sich ausmachen, was für ihn besser geeignet wäre. Das einzige, was ich empfehlen könnte, wäre ein Praktikum zu absolvieren. z.B. als Softwareentwickler, um mal zu sehen, ob das Thema überhaupt einen schmeckt. In meiner Ausbildung hatte ich auch viele Kommilitonen, die sich anfänglich für die Softwareentwicklung interessiert haben aber später doch die Ausbildung abbrachen, weil es doch schwieriger war, als sie dachten.

Dann könnte man sich auch überlegen, die Spiellogik in eigene Klassen auszulagern, anstatt sie in eine Form zu schreiben, damit das Spiel von der grafischen Oberfläche unabhängig wird.

Schaue dir mal die for-Schleifen genauer an. i ist bei dir die Breite und f die Höhe. Dein Array hast du aber andersrum definiert.

Es wird eine Exception geworfen. Sprich es kommt zu einem Fehler. Deswegen macht er nicht weiter. Allerdings bekommst du die Exception nicht mit, da sie vom Debugger nicht abgefangen wird. Aktiviere mal alle Exceptions unter Debuggen -> Fenster -> Ausnahmeeinstellungen (auf englisch: Debug -> Window -> Exception Settings). Dann solltest du auch die Exceptions bekommen, warum er nicht weitermacht.

Der Ansatz ist schon mal richtig. Schaue dir aber mal x und y an und versuche mit dem Debugger mal herauszufinden, welche Werte sie bei jedem Durchlauf haben. Vielleicht kommst du selber drauf, was los ist. Allerdings brauchst du x und y im Grunde gar nicht. Die Werte lassen sich auch mit einer einfachen Multiplikation errechnen: 1 * 50 = 50 2 * 50 = 100 3 * 50 = 150

Es kommt eine IndexOutOfRangeException, wenn i = 6 ist. Der Grund ist, du hast zwar die erste Dimension vom Array mit einer Größe von 6 definiert aber der Index fängt bei 0 an zu zählen. D.h. wenn i gleich 6 ist, greifst du somit quasi auf das 7. Element zu und das liegt außerhalb des Bereichs und es kommt zu einer Exception. Das gleiche gilt auch für f. Allerdings sehe ich noch einen weiteren Fehler: picbox[6, f] Die 6 müsste erst mal eine 5 sein aber das ist nicht der Fehler, den ich meinte. Mit der ersten for-Schleife definierst du nur die oberste Zeile und mit der zweiten for-Schleife die letzte Spalte. Zumal ist das Codeverdoppelung, was man vermeiden sollte. Es hat also noch Verbesserungspotenzial. Du kannst auch Schleifen in einer Schleife schreiben. Also: for(...) { for(...) { ... } }

Eine Ausbildung ist aber dennoch was anderes, als das Lernen aus Büchern oder Videos. Lernen aus Büchern oder Videos werden dir keinen guten Programmierstil vermitteln können, weil du u.a. kein Code Review durchführen kannst. Mit wem auch? Gerade im Dialog mit anderen Entwicklern lernt man sehr viel. Es bringt ja nichts, wenn man zwar jedes Problem schnell gelöst bekommt, man aber der einzige ist, der den Code überhaupt versteht oder der code nur Spaghetticode ist. Man sieht ja auch, dass der Trend vermehrt zum Pair-Programming geht. Es dauert zwar etwas länger aber der daraus resultierende Code ist lesbarer und stabiler.

Im Berufsleben kommt es eher später darauf an, welche Referenzen man vorzuweisen hat. Wenn ein FISI später hauptsächlich Entwicklertätigkeiten übernahm, hat man auch Chancen, als Entwickler irgendwo eingestellt zu werden. Es bringt also nichts, wenn du den AEler hinten ranhängst und dann doch nur Server administrierst. Man sollte aber auch nicht denken, nur weil man FIAEler ist, dass man sich plötzlich auf alle Entwicklerstellenangebote bewerben kann, denn auch hier kommt es auf die Referenzen an. Jemand, der z.B. hauptsächlich mit C# oder Java entwickelt, wird wohl kaum ein Job als COBOL-Entwickler finden. Das betrifft allerdings nicht nur die Sprachen, sondern auch die Technologien, die man im Laufe seiner Berufszeit verwendet hat. Jemand der z.B. zwar mit C# entwickelt aber noch nie was mit WPF zu tun hatte, wird es schwierig haben, einen Job zu finden, wo WPF gefragt ist. Das ist nicht richtig. Es bringt dir keiner bei, wie man richtig programmiert. Richtiges Programmieren lernt man nicht aus Büchern, sondern nur durch Übung, Übung und noch mehr Übung. Bücher und Co. geben einem nur Hinweise, was man besser machen könnte aber die berühmte Silberkugel wird und kann dir keiner präsentieren. Oder meint jemand, der das Buch "Clean Code" von Robert C. Martin durchgelesen hat, plötzlich ein super Entwickler zu sein, der zu 100% die SOLID-Prinzipien einhalten kann? Tutorials geben oft nur Lösungen für einfache Beispiele und selbst da gibt es mal gute und mal schlechte Lösungen.

Hilfreich wäre auch Vererbung. So könnte man z.B. die Buttons mit weiteren Informationen ausstatten: public class MyButton : Button { public int Spalte { get; set; } } So hätte man z.B. einen Button, der die Spalten-Information besitzt und so könnte man jeden Button mit dem selben Event ausstatten. Man hat also nur noch eine Event-Implementierung, anstatt zig kopierte.

Ist doch völlig Banane, welches Gerät du nimmst. Du wirst in der Umschulung mit Sicherheit keine Apps dafür entwickeln, sondern Konsolen- oder Desktopanwendungen. Zum Anfang wohl eher nur Konsolenanwendungen. Eine Android-App zu entwickeln ist nämlich noch ein bisschen was anderes und da wird man wohl nicht die Zeit haben, das SDK zu erklären. Inzwischen kannst du auch mit C# und Xamarin Crossplattform-apps schreiben, die sowohl auf Android als auch auf iOS laufen. Es kommt also darauf an, was du in deiner Freizeit machen möchtest.

Theoretisch bräuchte man sowas gar nicht programmieren. Da gibt es Haufenweise ETL-Tools, die dies übernehmen könnten. Gut man müsste dann schauen, ob es für diese Tools Konnektoren für die Eingangsquelle (SAP?) gibt. Viel mit Datenbank hat das Projekt auch nicht zu tun. Die Tabellen werden ja schon vom Ticketsystem vorgegeben und müssen nicht selbst entworfen werden. Anstatt aber reine SQL-Queries abzufeuern würde ich mal schauen, ob das Ticketsystem eine API besitzt, mit der man von Außen Tickets generieren kann. Das ist der sichere Weg, da man nicht sicher sein kann, ob da nicht noch andere Routinen, während der Ticketerstellung, laufen, wie z.B. eine Generierung von Metadaten. So könnte man die XML-Datei einlesen und dann die API aufrufen. Allerdings sehe ich da auch Probleme mit der fachlichen Tiefe. Aus einer XML-Datei SQL-Insert-Queries zu bauen, ist im Grunde nur noch Fleißarbeit. Ihr dürft aber nicht vergessen, wenn ihr reine SQL-Queries abfeuert, umgeht ihr das Ticketsystem, weil dies davon nichts mitbekommt. Wenn, dann müsst ihr diese Fehler auch noch ins Ticketsystem übertragen und dann wird das Thema auf einmal sehr komplex. Darum sagte ich ja, dass ihr lieber mal schauen solltet, ob das Ticketsystem nicht eine API besitzt. Wir haben auch so tolle Kunden, die meinen, Daten per SQL-Queries in die Datenbank zu pumpen, anstatt unsere Import-Funktion zu verwenden. Wir nehmen da keinerlei Haftung, wenn da irgendwas schieflaufen sollte und es läuft da regelmäßig was schief.

Ich kenne mich jetzt nicht mit dem SQL Server gut aus aber ich weiß, dass er die Daten blockweise von der Festplatte in den Arbeitsspeicher überführt. Es wird wohl besser sein, wenn Festplatte und Server aufeinander abgestimmt sind.

Da bin ich leider auch ein bisschen raus, da ich mich mit Unity nicht wirklich auskenne. Da weiß ich nicht, wie man mit Unity arbeitet. Sorry. Aber ein kleiner Hinweis: Anstatt List<AudioClip> kannst du auch ein Dictionary<string, AudioClip> machen, dann brauchst du die foreach-Schleife nicht und die PlaySound-Methode lautet einfach: public void PlaySound(string audioClipToPlay) { if(this.soundClips.Exists(audioClipToPlay)) audioSource.PlayOneShot(this.soundClips[audioClipToPlay]); }

Partielle Klassen verwende ich so gut wie gar nicht, weil sie nur in sehr wenigen Situationen wirklich Sinn machen. Partielle Klassen wurden in C# auch nur wegen WinForms eingeführt, damit man den automatisch generierten Code vom selbstgeschriebenen Code kapseln kann. Früher war der generierte Code mit dem selbstgeschrieben Code in einer Datei, was sehr unübersichtlich wurde, weil der generierte Code für die WinForms-Applikation sehr lang werden konnte. Ich kenne dein Code jetzt nicht aber in der Regel entwickelt man Interfaces, die dann die Klassen implementieren und die Klassen werden dann per Inversion of Control bzw. Dependency Injection zusammengefügt. Also die Abhängigkeiten einer Klasse werden vom Erzeuger reingereicht. So könnte man z.B. ein Interface für die Sounds definieren: public interface ISound { void Play(); } public class PlayerSound : ISound { public void Play() { \\ Spiele Sound } } Per Inversion of Control wird dies jetzt mit dem Player verbunden: public class Player { public ISound Sound { get; private set; } public Player(ISound sound) { this.Sound = sound; } } Man sieht hier also, um eine Instanz von der Player-Klasse zu erzeugen, brauchen wir auch eine Instanz, die das ISound-Interface implementiert. Zum Erzeugen der Player-Klasse müssen wir dann folgendes aufrufen: var player = new Player(new PlayerSound()); Auf diese Weise ist die Player-Klasse nicht mehr hart mit den Sounds verdrahtet und können die Sounds einfach austauschen. Beispiel: public class PlayerASound : ISound { public void Play() { \\ Spiele "Uff" } } public class PlayerBSound : ISound { public void Play() { \\ Spiele "Ahh" } } var spielerA = new Player(new PlayerASound()); var spielerB = new Player(new PlayerBSound()); // ... spielerA.Sound.Play(); // Spielt "Uff" spielerB.Sound.Play(); // Spielt "Ahh"

Definitiv! Schaue dir dazu die sog. SOLID-Prinzipien an. Dein PlayserScript verstößt schon gegen das Single-Responsibility-Prinzip, weil es mehr als eine Verantwortung trägt. Es ist ja quasi für alles verantwortlich und das darf nicht sein. Daher ist der erste Schritt, all die Methoden und die Klassenvariablen in ihre Verantwortlichkeiten zu separieren und daraus einzelne Klassen machen.

Doch sind sie, weil man erst mal herausfinden muss, wo genau der Schuh drückt und wer dafür verantwortlich ist. Das ist unabhängig, ob man ein kritisches System hat oder nicht. Auch ein Support braucht Zeit und in dieser Zeit muss man mit dem Fehler leben.

Gilt auch für Closed Source-Software. Ich bezweifel stark, nur weil man eine Lizenz gekauft hat, die Software plötzlich wie von Geisterhand bedienen lässt oder sich mit einem Klick in eine bestehende Umgebung integrieren lässt. Außerdem läuft man bei Dritt-Software, egal ob closed oder open source, immer die Gefahr, von dieser abhängig zu werden. Also sind deine Risikokosten immer dieselben. Das ist Unsinn. Auch Closed Source-Software hat Bugs. Wir haben auch schon etliche Tickets bei Oracle eingestellt und mussten dennoch etliche Workarounds schreiben, weil Oracle die Bugs nicht beheben will bzw. in der Priorität ganz unten stehen und wir sind Oracle Gold Partner. Selbst wenn man ein Bug in einer Closed Source-Software findet und diesen nicht beheben braucht, muss man erst mal mit diesem Fehler leben, bis er behoben ist und das kann schon mal sehr lange dauern, denn Support heißt nicht "sofortige Fehlerbehebung".

§15 Abs. 8 ITKTAusbV: D.h. du musst in deiner Projektarbeit, GA I, GA II und WiSo überall mindestens eine 4 haben, um zu bestehen. In GA I hast du maximum eine 5 und somit nicht bestanden.