Whiz-zarD

Für einen FIAEler könnte ich mir viele Projekte ohne SQL und relationale Datenbanken vorstellen.
Das ist ja nicht die einzige Form, wie Daten persistiert werden können. Es gibt sogar viele Szenarien, wo relationale Datenbanken ungeeignet sind.
Wobei ich mich weiterhin frage, wofür das Script auf den Clients gut sein soll?
Es ist von dem Einsatz eines Monitoring-Tools die Rede. Kann das Tool nicht die An- und Abmeldezeiten protokollieren?

Der Grund für die Exception ist, dass load(string uri) intern einen XmlTextReader instanziiert. Der schaut nach, ob die Encoding-Deklaration vorhanden ist. Falls nicht, wird standardmäßig UTF-8 als Encoding gewählt. Der XmlTextReader versucht daraufhin die Zeichen zu interpretieren und fällt bei dem å auf die Nase, weil die Datei nicht UTF-8 kodiert ist.
Der StreamReader ist auch nichts anderes, als ein TextReader, von daher kann auch dieser genommen werden, wie @Gottlike schon schrieb.

strecken_beginn = Zeile.Spalten[0]; strecken_ende = Zeile.Spalten.Anzahl - 1; frachtkapazitaet = holeStreckeGewicht(strecken_beginn, strecken_ende); Das kann doch nicht funktionieren, da strecken_beginn immer A und strecken_ende immer B ist. Demnach ist frachtkapazitaet immer gleich. Auch ist strecken_ende bei dir ein Integer ist und kein String.
Demnach müsste man z.B. bei der zweiten Route ( A - C - B ) die freie Kapazität für A - C und C - B ermitteln. Hier müsste man also eine verschachtelte Schleife bauen, die für alle Streckenabschnitte ermittelt, ob eine Strecke genügend Kapazität liefert
 
 
 

strecken_beginn = Zeile.Spalten[0]; strecken_ende = Zeile.Spalten.Anzahl - 1; frachtkapazitaet = holeStreckeGewicht(strecken_beginn, strecken_ende); Das kann doch nicht funktionieren, da strecken_beginn immer A und strecken_ende immer B ist. Demnach ist frachtkapazitaet immer gleich. Auch ist strecken_ende bei dir ein Integer ist und kein String.
Demnach müsste man z.B. bei der zweiten Route ( A - C - B ) die freie Kapazität für A - C und C - B ermitteln. Hier müsste man also eine verschachtelte Schleife bauen, die für alle Streckenabschnitte ermittelt, ob eine Strecke genügend Kapazität liefert
 
 
 

Ich finde, du solltest vielleicht erst mal von deinem hohen Ross runterkommen. Mag vielleicht nicht so sein aber deine Texte klingen doch sehr überheblich. In den letzten zwei Jahren habe ich viele solcher "Wunderkinder" gesehen, die von sich  behaupten, sie seien die coolsten Hacker, weil sie das eine oder andere Projekt auf Github veröffentlicht  und in einer Firma 0815-Arbeit getan haben, was Mami und Papi arrangiert haben, weil der kleine Sprössling ja so gut mit Computer umgehen kann aber was sie produziert haben, war für den professionellen und alltäglichen Einsatz nicht zu gebrauchen. Sie sind ja noch Kinder ohne Erfahrung. 
Nur weil du die Syntax und ggf. einige Frameworks einer Sprache kennst, heißt es noch lange nicht, dass du auch ein guter Entwickler bist, denn dazu gehört z.B. auch ein Verständnis für, wie man sauberen und gut strukturierten Code schreibt, denn Code wird mehr gelesen, als geschrieben.
Was ich schon merkwürdig finde ist, dass du schreibst du hättest Erfahrung mit Visual Studio aber in deiner Liste der Programmiersprachen taucht kein Visual Basic, C# oder F# auf. Vielleicht meinst du ja mit C++ aber auch Microsofts C++/CLI. Zwischen C++ und C++/CLI gibt es noch viele Unterschiede. 
Wie man Reverse Engineering gut beherrschen kann, ist mir auch ein Rätsel. Nur weil man evtl. ein paar Sprungmarken umschreiben kann, um somit die Passwortabfrage zu umgehen, heißt es noch lange nicht, dass man den tatsächlichen Algorithmus dahinter verstanden hat. 
Ich selber würde erst mal das Abitur fertig machen. Schaden kann es nicht und wenn man gute schulische Leistungen erbringt, kann man auch die Ausbildungszeit verkürzen oder die Abschlussprüfung vorziehen. Ein Abbrechen des Abiturs halte ich nicht für schlau.
 

Ist zwar richtig aber sowohl Java als Webplattform als auch ASP.NET verlieren ihre Bedeutung im Web, da der Trend Richtung Single Page Applications (SPAs) und Web-APIs geht. Im Frontend-Bereich werden dann JavaScript-Frameworks wie z.B. AngularJS oder React eingesetzt und im Backend ist es dann egal, welche Sprache man nimmt. Man ist dort nicht mehr so auf ein Technologie-Stack beschränkt, sondern kann das einsetzen, was am Besten für eine Situation ist. Das Frontend lässt sich dann auch leicht gegen eine andere Technologie austauschen, da die UI explizit vom Technologie-Stack der Logik getrennt wird. Dies ist bei ASP.NET oder JavaServer Pages nicht möglich.
Ich persönlich finde ASP.NET und Java Server Pages für kleine Applikationen zu schwergewichtig und für größere Applikationen, bei denen z.B. Nebenläufigkeiten (z.B. aufgrund von langen Berechnungszeiten) wichtig sind, ungeeignet. Auch verbraten diese Technologien sehr viel Rechenkapazitäten beim Rendern vom HTML, was auch der Client übernehmen könnte, was eben ein weiterer Vorteil von SPAs ist. 
Um auf das Topic zurückzukommen:
Ich denke auch, dass Java derzeit noch mehr verwendet wird. Vor allem weil auch für Android Java verwendet wird aber Java ist mit seinen Sprachfeatures schon etwas rückständig. C# holt da gerade massiv auf, weil es nun dank .Net Core auch Crossplattform-tauglich wird und es unterstützt auch self-containing, sodass man nicht mal mehr das .Net-Framework installieren braucht, sondern die erforderlichen .Net-Komponenten können gleich in die Binärdatei gepackt werden. 
 

http://www.ecma-international.org/publications/standards/Ecma-376.htm
Da zählt alles dazu, was man an Schriftarten einstellen kann.
Du kannst ja selbst den Test machen: Eine .xlsx-Datei ist nichts weiter, als eine .zip-Datei, die du entpacken kannst. Unter den Ordner xl\styles.xml findest du den <Fonts>-Bereich. 
Wie man das Problem lösen kann? Vernünftig mit Formatierungen arbeiten und sparsamer sein. Niemand braucht so viele Formate.

12 Stunden für eine Ist- und Sollanalyse? Halte ich für zu viel. Ansonsten sind auch die 13 Stunden für den Datenbankentwurf zu viel.

Wozu dann überhaupt ein Lasten- und Pflichtenheft? Da gibt es weitaus bessere und effizientere Methoden. Diese Hefte gehören IMO so langsam auf den Müll, denn die taugen nichts und sorgen nur für Probleme. In einem Lasten- und Pflichtenheft ist es eigentlich sehr schwer auf Änderungen zu reagieren, weil im Pflichtenheft schon genau drinnen steht, was und wie es umgesetzt werden soll und eine Anpassung gar nicht vorgesehen ist. Eine Änderung hätte auch zur Folge, dass man beide Hefte anpassen müsste, wenn es überhaupt dazu kommt. Viel effizienter wäre es, wenn man sich iterativ, in einem festgelegten Rhythmus trifft und über die derzeitige Implementierung spricht und dies in einem Protokoll festgehalten wird. Aber gut, die IHK will wohl weiter an an­ti­quare Methoden festhalten...
Bei Architekturen kann man sich dumm und dämlich reden aber ich gehe mal davon aus, dass man hier keine Raketenwissenschaft einführen möchte. Ich nehme an, dass du die selben Techniken verwenden willst, wie sonst auch in der Firma. Wozu muss man denn da über 10 Stunden reden? Du wirst ja schon ein bisschen Erfahrung mit PHP und CRUD-Operationen haben, denn ansonsten würdest du dieses Projekt nicht wählen wollen.

Meiner Meinung nach sollte gar kein Lasten- und Pflichtenheft mehr geschrieben werden, sondern mit den Kunden iterativ in einem festen Rhythmus die nächsten Schritte besprechen und diese formlos niederschreiben. Der Kunde weiß nie, was er genau will bzw. er weiß nicht, wie man es genau beschreibt und ein Pflichtenheft kann noch so gut geschrieben sein aber in fast allen Fällen versteht es der Kunde falsch oder es ergeben sich hinterher Änderungen, die im Pflichtenheft nicht berücksichtigt und zu spät umgesetzt worden sind.

Wozu dann überhaupt ein Lasten- und Pflichtenheft? Da gibt es weitaus bessere und effizientere Methoden. Diese Hefte gehören IMO so langsam auf den Müll, denn die taugen nichts und sorgen nur für Probleme. In einem Lasten- und Pflichtenheft ist es eigentlich sehr schwer auf Änderungen zu reagieren, weil im Pflichtenheft schon genau drinnen steht, was und wie es umgesetzt werden soll und eine Anpassung gar nicht vorgesehen ist. Eine Änderung hätte auch zur Folge, dass man beide Hefte anpassen müsste, wenn es überhaupt dazu kommt. Viel effizienter wäre es, wenn man sich iterativ, in einem festgelegten Rhythmus trifft und über die derzeitige Implementierung spricht und dies in einem Protokoll festgehalten wird. Aber gut, die IHK will wohl weiter an an­ti­quare Methoden festhalten...
Bei Architekturen kann man sich dumm und dämlich reden aber ich gehe mal davon aus, dass man hier keine Raketenwissenschaft einführen möchte. Ich nehme an, dass du die selben Techniken verwenden willst, wie sonst auch in der Firma. Wozu muss man denn da über 10 Stunden reden? Du wirst ja schon ein bisschen Erfahrung mit PHP und CRUD-Operationen haben, denn ansonsten würdest du dieses Projekt nicht wählen wollen.

Für .Net-Entwickler die Developer Week in Nürnberg und die Developer Conference in Köln. 
Die Developer Open Space in Leipzig soll auch sehr gut sein. 
Ansonsten mal unter Meetup.com nach Usergroups zu bestimmten Themen suchen. 

Ich habe einige Zeit lang in England gearbeitet: Dort läuft es über "references" - Du musst bei einer Bewerbung 2-3 ehemalige Vorgesetzte benennen, die dann von deinem zukünftigen Arbeitgeber befragt werden. Das kann in Form eines Telefonats sein aber durchaus beinhalten, dass ein Fragebogen verschickt wird, den der ehemalige Vorgesetze dann auszufüllen hat.

Danke. Ich hab schon an meine Kenntnisse gezweifelt. 

Und auch hier sieht man mal wieder das die IHK auch FALSCHE antworten geben kann.

Die Lösung ist : V2, D3 und D5.

Als Basis ist immer das Vollbackup zu verwenden. Somit kann die Lösung der IHK nicht passen.

Und nur weil der User nach Hilfe fragt , bedeutet es nicht das er keine Ahnung davon hat. Solche Behauptungen sollte man lassen.

Greetz UniBall.

Ich denke, dass dies sogar noch sehr optimistisch ist. Ich gehe davon aus, dass nahezu 100% aller Projekte den Zeitplan nicht einhalten. Ich halte sowieso nichts von exakter Stundenangabe, wie lange man für eine Tätigkeit benötigt. Der Zeitplan sollte lediglich nur ein Indiz sein, dass man das Projekt auch in der Zeit schaffen kann und eine gewisse Komplexität aufweist. In der Ausbildungsverordnung steht ja auch folgender Satz drinnen:
(Analog für die FISIs)
Laut Ausbildungsverordnung dürfen es sogar auch weniger sein. Es dürfen nur die 35/70 Stunden nicht überschritten werden. Die IHK sieht es aber anders, denn da müssen es exakt 35/70 Stunden sein, was aber eigentlich nicht stimmt. Da sieht man auch recht deutlich, dass man es hier überwiegend mit Bürokraten zu tun hat.
Das gilt auch für die Softwareentwicklung. Niemand kann im Vorwege sagen, dass eine Implementierung einer Lösung exakt 20 Stunden dauert. Auch in der Softwareentwicklung entwickelt man Strategien, um ein Problem zu lösen. Ob die Strategien aufgehen oder ob man noch Gegensteuern muss, weiß man im Vorwege nicht. Darum gibt es ja seit über 15 Jahren den Ansatz der agilen Softwareentwicklung, wo man eben in Iterationen arbeitet und schnell Feedback bekommt. Dieses Verfahren ist aber durch die IHK in der Abschlussprüfung gar nicht möglich, da die exakten Stunden einzuhalten sind, die man vorher beim Einreichen des Projektes festgelegt hat. Abweichungen sind zwar Möglich aber müssen später begründet werden und können ggf. nachteilig in die Benotung einfließen.

Aus eigener Erfahrung kann ich sagen, dass beide Punkte ein Trugschluss sind. Das Argument "Wenn man es selbst entwickelt, dann hat man keine Abhängigkeiten" habe ich schon so oft gehört und jedes Mal war es ein Fehler. Das Problem ist, dass man sich zu viel ins Unternehmen holt, was gar nicht das Kerngeschäft des Unternehmens ist. Als Beispiel kann ich die Firma nennen, wo ich gerade arbeite. Sie haben ihr O/R-Mapper selbst entwickelt, genau aus den genannten Gründen. Das Ding wird zunehmend ein gigantisches Problem, weil der performancetechnisch einfach nur Mist ist. Wir entwickeln eine Software für Banken. Wir müssen uns also nicht nur mit unserem Kerngeschäft auseinandersetzen, sondern haben noch Technologien, wie z.B. der O/R-Mapper warten. Sprich, wir können uns nicht zu 100% mit den Aufgaben der Kunden beschäftigen, weil wir selber intern zu viel an der Backe haben.
Kostengünstige Wartung erreicht man auch nicht, indem man die Applikation selbst entwickelt, denn irgendwer muss man auch den Entwickler dafür bezahlen. Also entweder kommandiert man ein Entwickler ab, der sich eigentlich um das Tagesgeschäft kümmern sollte und somit für diese Zeit kein Geld in die Kassen spült oder ich muss einen einstellen, der sich ausschließlich mit der In-House-Software beschäftigt. Nur weil man keine Lizenzverträge hat, heißt es noch lange nicht, dass eine Software günstiger ist. Eine In-House-Lösung kann auch sehr teuer werden. In den meisten Fällen wird diese nur Stiefmütterlich behandelt. Sprich, die wird halt irgendwie hingefrickelt. Interessiert doch eh keinen. Tests werden vernachlässigt, weil sie überflüssig sind und Geld kosten. Also lässt man sie weg. Ein Refactoring findet dann auch nicht statt. Läuft doch. Jeder frickelt neue Funktionen rein und nach einem Jahr ist die Applikation instabil, unwartbar und nur noch lästig.
Also ja, in der Theorie hast du recht (reicht vielleicht auch bei der Abschlussarbeit) aber die Praxis sieht leider anders aus.

Was ist denn aus deinem Vorhaben geworden, den FIAE im "Heimstudium" zu erlangen?
 
 

Konstruktoren sollte keine Logik besitzen. Wie der Name schon sagt, dient er zur Konstruktion eines Objektes. Daher sollte der Konstruktor auch nur dafür verwendet werden. Sprich, die Zeilen:
player.MoveTo(World.LocationById(World.location_id_fight)); MonsterAppear(this, new EventArgs()); Sollten da raus.
 
 

Das schon eher (auch wenn das auch nicht nicht sauber ist). Ein Hinweis, dass die beiden genannten Zeilen nicht in die Fight-Klasse gehören, ist auch deren Funktion.
Du bewegst den Spieler und ein Monster erscheint. Das ist aber noch vor dem Kampf und somit verletzt man das sog. Single-Responsibility-Prinzip. Sprich, die Klasse hat mehr als eine Zuständigkeit, indem die Klasse den Spieler bewegt, das Ereignis auslöst und den Kampf an sich.

Du reichst Player und Monster in den Konstruktor der Fight-klasse rein und speicherst diese dann als Membervariable in dieser Klasse ab.

Ein weiterer Tipp: Solche Konstruktoren, wie z.B.
public Player(int curHP, int maxHP, int gold, int curExp, int maxExp, int level, int attack) { ... } Sind unter C# nicht nötig und auch beim Aufruf schlecht lesbar. Keiner wird auf den ersten Blick verstehen, welche Parameter was ist:
private Player _player = new Player(20, 20, 0, 0, 10, 1, 2); Man muss den Konstruktor kennen, um zu wissen, was z.B. die letzte 2 bedeutet. C# bietet hier den Objectinitializer, der das Ganze lesbarer macht:
private player = new Player { CurHP = 20, MaxHP = 20, Gold = 0, CurExp = 0, MaxExp = 10, Level = 1, Attack = 2 };
Anstatt eine List<Monster> zu nehmen, um darüber dann zu iterieren, um das jeweilige Monster mit der Id herauszusuchen, verwendet ein Dictionary<int, Monster>. Beispiel:
public Dictionary<int, Monster> monsters = new Dictionary<int, Monster> { { monster_id_wolf, new Monster(monster_id_wolf, "Wolf", 10, 10, 1, 10, 2, 1) }, { monster_id_bee, new Monster(monster_id_bee, monster_id_bee, "Bee", 1, 1, 1, 1, 1, 1) } } Dann brauchst du die MonsterById()-Methode nicht mehr, sondern kannst direkt mit monsters[monster_id_wolf] darauf zugreifen. Natürlich kannst du auch hier den oben genannten Tipp mit dem Konstruktor nehmen.
Ansonsten ist da noch sehr viel, was man anders machen sollte aber darüber zu reden bringt wohl nichts.

Ich habe keine hohen Ansprüche. Das Problem ist einfach, dass dir nicht klar ist, was du da eigentlich tust und das wird zu Frustration führen. Du willst auch nichts dazu lernen, indem du dich strikt weigerst neue Dinge zu lernen und mit deinem Laienwissen bist du noch nicht so weit, ansatzweise sowas aufbauen zu können.
Das fängt schon damit an, dass du Klassen und Membervariablen static machst, ohne den Sinn dahinter zu verstehen und was das bedeutet, wenn du diese static machst.

Web-Applikationen sind auch nicht mehr das "Nonplusultra". Der Trend geht in Richtung Mobile-First. D.h. es wird zuerst eine Mobile-App entwickelt, bevor man eine Web-App entwickelt. PHP- und ASP.NET-Anwendungen sind auch schon auf dem Rückzug. Sie werden uns zwar noch viele Jahre begleiten aber der Trend in Web-Apps geht in Richtung sog. Single-Page-Applikationen (SPA). SPAs haben den Vorteil, dass der Server entlastet wird, indem das Rendering auf dem Client stattfindet. D.h. der Server schickt nur noch die rohen Daten zum Client (Browser) und der Browser bastelt daraus selbst das HTML-Dokument. Für SPAs braucht man auch keinen dicken Webserver ala Apache, sondern es reicht auch was leichtgewichtiges, was die Anfragen annimmt und jemandem damit beauftragt. In der .NET-Welt gibt es z.B. NancyFx, was einen HTTP-Request annimmt und verarbeiten kann. NancyFx ist angelehnt an das Ruby-Projekt Sinatra. NancyFx könnte also z.B. ein HTTP-Request entgegennehmen und es an einen Microservice weiterleiten und das Ergebnis zurück zum Client schicken. Auf dem Client läuft dann ein Framework ala AngularJS oder React, mit denen dann die HTML-Dokumente erstellt werden.
Klassische WinForms Anwendungen gibt es zwar noch in der Business-Welt aber die sind eher historisch begründet. Wir entwickeln auch noch eine aber wir haben mit der Planung der nächsten Generation angefangen und die deutliche Mehrheit unserer Kunden (Banken) wollen keine Desktop-Applikation, weil sie damit einen höheren Aufwand haben, da sie virtuelle Desktops bereitstellen müssen. Auch der Trend bei unseren Kunden geht also hin zu mobilen Endgeräten. 
Also nein, auf Desktop-Anwendungen würde ich heutzutage nicht mehr setzen, es sei denn, du hast da was sehr spezielles, was in einem Browser nicht funktioniert oder vom Vorteil wäre, wenn es auf einem Desktop läuft aber selbst bei 3D-Grafiken ist WebGL da schon sehr weit. Man muss auch berücksichtigen, dass selbst bei Ottonormalverbrauchern der Trend in Richtung Mobile-Geräten geht und da sollte man sich schon fragen, ob es Klug ist, eine sehr große Klientel auszugrenzen. 

Web-Applikationen sind auch nicht mehr das "Nonplusultra". Der Trend geht in Richtung Mobile-First. D.h. es wird zuerst eine Mobile-App entwickelt, bevor man eine Web-App entwickelt. PHP- und ASP.NET-Anwendungen sind auch schon auf dem Rückzug. Sie werden uns zwar noch viele Jahre begleiten aber der Trend in Web-Apps geht in Richtung sog. Single-Page-Applikationen (SPA). SPAs haben den Vorteil, dass der Server entlastet wird, indem das Rendering auf dem Client stattfindet. D.h. der Server schickt nur noch die rohen Daten zum Client (Browser) und der Browser bastelt daraus selbst das HTML-Dokument. Für SPAs braucht man auch keinen dicken Webserver ala Apache, sondern es reicht auch was leichtgewichtiges, was die Anfragen annimmt und jemandem damit beauftragt. In der .NET-Welt gibt es z.B. NancyFx, was einen HTTP-Request annimmt und verarbeiten kann. NancyFx ist angelehnt an das Ruby-Projekt Sinatra. NancyFx könnte also z.B. ein HTTP-Request entgegennehmen und es an einen Microservice weiterleiten und das Ergebnis zurück zum Client schicken. Auf dem Client läuft dann ein Framework ala AngularJS oder React, mit denen dann die HTML-Dokumente erstellt werden.
Klassische WinForms Anwendungen gibt es zwar noch in der Business-Welt aber die sind eher historisch begründet. Wir entwickeln auch noch eine aber wir haben mit der Planung der nächsten Generation angefangen und die deutliche Mehrheit unserer Kunden (Banken) wollen keine Desktop-Applikation, weil sie damit einen höheren Aufwand haben, da sie virtuelle Desktops bereitstellen müssen. Auch der Trend bei unseren Kunden geht also hin zu mobilen Endgeräten. 
Also nein, auf Desktop-Anwendungen würde ich heutzutage nicht mehr setzen, es sei denn, du hast da was sehr spezielles, was in einem Browser nicht funktioniert oder vom Vorteil wäre, wenn es auf einem Desktop läuft aber selbst bei 3D-Grafiken ist WebGL da schon sehr weit. Man muss auch berücksichtigen, dass selbst bei Ottonormalverbrauchern der Trend in Richtung Mobile-Geräten geht und da sollte man sich schon fragen, ob es Klug ist, eine sehr große Klientel auszugrenzen.