Whiz-zarD

Wenn man wegen persönliche Belange nicht genommen wird, dann ist es eh eine schlechte Firma. Wir sind Menschen und keine Maschinen. Wir setzen Prioritäten und wenn deine Priorität ist, dass du dein Kind öfters sehen möchtest, dann ist das so. Ich wüsste jetzt nicht, warum man dort nicht die Wahrheit sagen sollte.

Wenn man da nicht sogar noch draufzahlt, weil die Entwicklung und der Support nun plötzlich doch intensiver werden, als angenommen. Man entwickelt ja nicht einfach mal so ein Tool und dann läuft es für alle Ewigkeiten ohne sich noch mal die Finger krumm zu machen, sondern wenn es in eigener Hand ist, kommen dann plötzlich diese und jene Wünsche und das Tool muss laufend gewartet werden. Dies sind Kosten, die meist nie eingerechnet werden und auch nie in einen monetären Gewinn umschlagen, da man dieses Tool eben nicht vertreibt. Eigenlösungen werden auch häufig auch nur hingefrickelt, weil sie eben nicht zum Tagesgeschäft gehören und Zeit fressen. Aber ja, ich würde auch sagen, dass es für ein Abschlussprojekt reicht, auch wenn ich es sehr skeptisch sehe, dass damit Geld eingespart wird.

Vielen Dank @stefan.macke Einen sehr groben Plan als solches habe ich ja. Es ist mir auch klar, dass eine Firma einen Ausbildungsplan aufstellen soll. Ich finde es halt nur merkwürdig, dass die Handelskammer quasi schon den Plan vorgibt, wie der abzuarbeiten ist. Zumal wirkt er in einigen Stellen nicht richtig durchdacht. Wie ich schon sagte, im ersten Lehrjahr soll der Azubi schon Anwendungen modular und unter Berücksichtigungen von Wartbarkeit und Sicherheit entwickeln können aber erst im zweiten Lehrjahr soll er sich die Entwicklungsumgebungen anschauen. Von einem Tischler-Azubi erwartet man ja auch nicht, dass er als erstes einen Stuhl bauen kann und sich erst dann beschäftigt, was ein Hammer und eine Säge ist. Auch greifen viele Punkte ineinander, wie z.B. der Punkt "Teamarbeit". Wir arbeiten hier nur in Teams, von daher ist die Teamarbeit ganzjährig. Ich denke mal, allgemein lässt sich schlecht sagen, dass der Azubi von dann bis dann die Fertigkeit "Teamarbeit" gelernt hat. Wir sind ja nicht in einem Videospiel, wo plötzlich ein "+1 Teamarbeit" über dem Kopf aufploppt. Aber ist es eigentlich neu, dass dies nun mit zum Ausbildungsvertrag dazugehört? Ich habe sowas noch nie gesehen. Gut, meine Mechatroniker-Ausbildung (2000 - 2004) ist schon ein bisschen her aber bei unseren damaligen FISI-Azubi (vor 3 Jahren ausgelernt) und den Azubis im Personal-Bereich musste sowas auch nicht ausgefüllt werden.

Hab die Handelskammer mal angefragt und man sagte mir, dass es reichen würde, wenn ich nur das erste Lehrjahr ausfülle. Ich finde es aber dennoch seltsam, was hier getrieben wird. Zu mal die Einteilung sehr willkürlich wirkt.

Hallo, wir stellen nun am 1. August unseren ersten FIAE-Azubi ein. Von der Handelskammer bekamen wir ein Anlagenbogen für den Ausbildungsvertrag, in dem wir eintragen sollen, von wann bis wann der Azubi welche Fertigkeiten und Kenntnisse erlernt. (Beispiel siehe Anhang) Ist dies so bei den anderen IHKs gängige Praxis und wenn ja, wie geht ihr dort vor? Ich finde das echt schwer. Zumal die Lernziele ja nicht so wie eine Todo-Liste abgehakt werden können, da es ja auch abhängig vom Kenntnisstand des Azubis ist. Auch kann ich nicht drei Jahre im Voraus planen, wann er was macht. Die Einteilung, die hier vorgegeben wird, ist auch sehr schlecht. Der Azubi soll im ersten Lehrjahr schon wissen, wie man eine Software modular entwickelt aber im zweiten Lehrjahr wird sich erst die Entwicklungsumgebung angeschaut. Das passt doch auch nicht zusammen.

Irgendwie sind die Informationen ein bisschen dürftig aber es klingt für mich, als ob ihr überhaupt nichts großartiges braucht. Sucht euch da einfach ein Mini-PC und ihr seid wohl damit glücklich.

Und in welcher Sprache wurde die Benutzeroberfläche entwickelt? Soll sie ebenfalls auf dem Server laufen?

Entscheidend ist doch, was ihr mit dem Server macht und welche Spezifikationen er braucht. Werden da nur ein paar Einträge in einer MySQL-Datenbank gepflegt, würde doch auch schon, überspitzt gesagt, ein Raspberry Pi reichen.

Dazu fällt mir noch Jugend Hackt ein.

gelöscht

Die Properties in C# sind aber auch nur syntaktischer Zucker, da der Compiler die in Methoden umbaut, wie in Java. Also aus public string Name { get; set; } baut der Compiler dies: private string _name; public string _getName() { return this._name; } public void _setName(string value) { this._name = value; } Und somit sind Properties das selbe, wie die Getter und Setter in Java. Es ist halt nur eine kürzere Schreibweise.

Haben wohl mehrere einen Vertrag zugeschickt und wer zuerst kommt, mahlt dann zuerst.

Du kannst fünf Leute fragen und bekommt sechs Antworten. Ich persönlich habe früher mit Java entwickelt, weil ich damals plattformunabhängig entwickeln wollte und .net so ein auf Windows spezieller proprietärer Kram war. C# wollte ich daher nie anfassen. Erste C#-Erfahrung sammelte ich dann in meiner Ausbildung bezüglich einer Seminararbeit über die Spieleentwicklung mit dem XNA-Framework. Später landete ich dann in einer Firma, die mit C# arbeitet und heute muss ich sagen, dass ich lieber mit C# arbeite anstatt mit Java. C# bekommt auch immer mehr Einflüsse aus der funktionalen Programmierung, die das Leben schon erleichtern. Inzwischen liegt auch der Quellcode offen und lässt sich ohne große Mühe für andere Plattformen ausrollen. Nicht desto trotz gibt es derzeit aber immer noch mehr Stellenangebote für Java-Entwickler und ich denke, das wird auch für einige Jahre so bleiben, da viele Business-Software damit entwickelt worden sind, die weiterhin laufen werden. Es ist also mehr eine persönliche Präferenz, ob man nun Java oder C# nimmt. Von der allgemeinen Syntax her sind aber beide Sprachen sehr ähnlich.

Die Klausel, dass alle Überstunden mit dem Gehalt abgegolten sind, ist unwirksam. Diese Klausel ist nur gültig, wenn explizit eine Anzahl an Überstunden erwähnt wird. Wenn, dann würde ich den Arbeitgeber noch mal darauf hinweisen. Diese Klausel wurde schon vor 9 Jahren einkassiert und ich finde es immer noch erschreckend, dass viele Arbeitnehmer und -Geber dies nicht wissen bzw. Arbeitgeber es immer noch versuchen, diese Klausel durchzudrücken.

Wobei die Frage ist, was die "Erfahrenen" mit ihren Erkenntnissen machen? Teilen sie es den Azubi mit? Geben sie dem Azubi Tipps, wie man es besser machen könnte oder auch mal Lob? Oder korrigieren sie stillschweigend die Fehler und ärgern sich über den Azubi? Wenn letzeres, dann ist das kein guter Umgang mit einem Azubi. In wiefern ein Henne-Ei-Problem? Das ist genau der Schwachsinn, wenn es heißt: "Tut uns leid aber mir müssen leider absagen, da sie keine Berufserfahrung haben." Dass ein Azubi keine Erfahrung in Projekten hat, ist logisch. Woher soll er auch sie haben? Dennoch muss man ihn in Projekten einplanen, ansonsten bekommt er nun mal keine Erfahrungen. Wer Azubis nicht in Projekten einbindet, weil sie keine Erfahrung haben, hat ein Problem in der Personalplanung. Punkt. Das ist kein Henne-Ei-Problem.

Ohne das Projekt zu kennen, ist es auch meine Vermutung, dass das Projekt zu groß ist. Wir reden hier von höchstens 70 Stunden, wobei noch einige Stunden für Organisation und Dokumentation draufgehen. Bei einer 35 Stundenwoche würde das Projekt zehn Werktage dauern. Die Entwicklungszeit wären dann ca. 6-7 Tage. Das ist eine sehr kurze Zeit, die man überblicken kann. Wenn es aber plötzlich 18 Tage dauert ohne dass sich die Anforderungen geändert hat, dann stimmt was mit der Planung nicht und das hätte auffallen müssen. Sicherlich, es gibt immer Momente, wo man sich komplett verschätzt. Ist mir auch schon passiert, dass ich gesagt habe, dass ich für ein Feature zwei Tage benötige aber hinterher 20 daraus wurden aber hier guckt eigentlich der Ausbilder und der Prüfungsausschuss noch mal drüber.

Beides ist das selbe. Allerdings kann die Schreibweise char* argv[] in die Irre führen. Beispiel: char* c1, c2; welchen Typ hat nun c2? char oder char*. Die Antwort ist char. Nur c1 ist char*. Es wäre also besser, man schreibt char *c1, c2; oder man trennt es gleich: char *c1; char c2; Der Grund für diese unterschiedliche Schreibweise liegt in den Unterschieden zwischen C und C++. In C schreibt man char *c1. Weil es der Zeiger auf ein char ist. In C++ ist es üblich, den Typen und dann den Variablennamen zu schreiben. Der Typ ist ja ein Zeiger auf ein char. Also char* c1. Da aber C++ nur eine Erweiterung von C ist, versteht der Compiler beide schreibweisen.

Für mich auch zu kompliziert. Ich hab ein Girokonto und ein Sparbuch. Mehr brauche ich fürs Tagesgeld nicht. Zinsen sind derzeit eh nicht zu erwarten. Daneben habe ich dann ein Bausparvertrag, drei Aktienfonds (die mehr oder weniger gut funktionieren) und ne betriebliche Altersversorgung. Bei den Versicherungen habe ich ne Kfz-, Hausrat-, private Haftpflicht- und Unfallversicherung.

Joa, im idealfall nur eine. Zwei können es auch noch sein, z.B. eine für die Überschrift und eine für den Text. Was aber gar nicht geht, sind Serifenschriften. Sie mögen zwar auf Papier besser für den Lesefluss sein, aber auf Bildschirmen sind sie schlechter lesbar, da sie nicht ganz so scharf dargestellt werden können. Außerdem wirken solche Schriftarten altbacken. Ebenfalls altbacken wirken 3D-Effekte, wie z.B. der Schatten. Der Standard das sog. Flat Design.

Derzeit arbeite ich eine Anzeige für einen Ausbidlungsplatz aus und hab zur Recherche mal nachgeschaut, was so andere Firmen schreiben. Da bin ich auf etliche Firmen gestoßen, die von den Azubis schon Kenntnisse zu OOP und Datenbanken voraussetzen. Witzig ist auch, dass gerade diese Firmen damit werben, dass sie eine großzügige Ausbildungsvergütung bezahlen. Ein Junior Entwickler ist denen wohl zu teuer. Also ködern sie mit der höheren Vergütung junge Leute und setzen sie als billige Arbeitskraft ein.

Er soll nur irgendwas präsentieren, was er in der Schule oder in einem Hobby erstellt hat. Der könnte jetzt auch einen Papierflieger präsentieren. Das ist ein Übungsstück und hat auch was mit Physik und Technik zu tun.

In der Spieleindustrie zu arbeiten hört sich immer im ersten Moment sehr romantisch an: Man arbeitet in einem lustigen, bunten Team an tollen Spielen. So romantisch ist ein Job in der Spieleindustrie nicht. Eher würde ich davon abraten. Es werden massig Überstunden verlangt bei einer beschissenen Bezahlung. Ich weiß, dass sogar einige deutsche Spielefirmen versucht haben, den Mindestlohn zu prellen, indem die Mitarbeiter gezwungen worden waren, eine Verzichtserklärung zu unterschreiben. Falls sie es nicht täten, waren sie ihren Job los. Auch stellen die meisten Firmen nur Praktikanten ein. Besonders beliebt sind Praktikanten, die ein Plfichtpraktikum absolvieren müssen. Die muss man nämlich nicht bezahlen. @ Topic: Wie schon erwähnt, kommt es darauf an, was sie unter "Game Design" verstehen. Die Kurse, die ich zu diesem Thema kenne, geht es eher um das Konzeptionieren von Ideen und nicht um das technische. Solche Kurse dauern ja auch nur ein Jahr in Vollzeit. Anders ist es, wenn man in Richtung "Game Programming" geht. Dort geht es um das Technische, wobei dort auch nicht unbedingt viel Mathematik gefordert wird, weil die Engines die meiste Arbeit schon abnehmen. In so einem Kurs wird man vielleicht etwas mit Transformationen, Belichtungsmodellen und Shadern zu tun haben und ggf. fängt man im Low-Level bereich an, um den Game Loop zu verstehen aber eigentlich können es sich nur noch große Konzerne leisten, eigene Engines zu schreiben. Die meisten Firmen setzen auf fertige Engines und da ist sowas, wie eine Physikengine schon enthalten. Auch Programmieren muss man nicht wirklich viel. Das nimmt auch schon die Engine ab. Es geht dann überwiegend nur noch darum, was passiert, wenn Button X gedrückt wird oder Event Y ausgelöst wird.

Wie @Defneqon schon sagt, Kanban ist keine agile Methode um Software zu entwickeln. Kanban macht eigentlich nur den Prozess transparent und zeigt die Schwächen eines Prozesses auf, wie z.B. wenn ständig das WIP-Limit (Work in Progress) überschritten wird. Das bedeutet dann, dass die Mitarbeiter zu viele Dinge gleichzeitig tun müssen. "Agil" geistert seit einigen Jahren als Buzzword durch die IT-Welt aber man sollte sich fragen, was das Wort überhaupt bedeutet? Agil heißt nämlich nicht, dass alles chaotisch verläuft und jeder tun und machen kann, was er will und einfach mal kurz in die Entwicklungsabteilung schreien kann und die Entwickler machen es schon. "Agil" heißt im Grunde "Kommunikation" und zwar auf allen Kanälen. Man entwickelt nämlich nicht Monate lang ein Pflichten- und Lastenheft, sperrt die Entwickler sechs Monate ein und raus kommt ein unfertiges Produkt, sondern man kommuniziert kontinuierlich mit dem Kunden und erörtert, was gut ist und was Verbesserungen bedarf. Das setzt auch voraus, dass der Kunde was sehen und anfassen kann. Sprich, es müssen in kurzen Abständen benutzbare Software-Releases bereitgestellt werden, die dann der Kunde begutachten kann. Auch darf der Kunde jeder Zeit neue Wünsche äußern. Die Software entwickelt sich also in kleinen Schritten und bei solchen Schritten ist es dann schwierig sowas wie Meilensteine zu setzen, weil man nicht weiß, wie sich der Prozess entwickelt. Kann ja sein, dass ein Feature mehrere Runden drehen muss, bis es dem Kunden passt. Das müssen jetzt nicht unbedingt Softwarefehler sein, sondern einfach z.B. dass der Kunde selber nicht mal so weiß, was er eigentlich möchte und es werden einfach mal mehrere Dinge ausprobiert. Das wichtigste an agiler Softwaremethoden also nicht, dass man tolle Prozesse wie z.B. Kanban oder etwas Scrum-ähnliches eingeführt hat, sondern das kontinuierliche Feedback und zwar seitens des Kundens und auch seitens des Teams. Man kann zwar toll Scrum einführen aber wenn die Phasen des Reviews und der Retrospektiven fehlen, dann ist es nicht agil, sondern einfach nur kurze Wasserfälle.

Dann verwendest du halt entweder die JNI, für eine C bzw C++-Assembly oder jni4net für eine .Net-Assembly

Meine C Kenntnisse sind schon sehr eingerostet aber du machst ja nichts mit menge. Du durchläufst zwar eine Schleife, dessen Anzahl der Durchläufe der menge entspricht aber du setzt den Pointer nicht auf das nächste Element. Daher wird in jedem Schleifendurchlauf immer nur das erste Element verändert.