pr0gg3r

Dann gedulde dich, das kommt von Zeit zu Zeit. Eigentlich gehört das (meiner Meinung nach) auch mit zu den Aufgaben deines Ausbildungsbetriebes, jedoch legt nicht jeder Betrieb Wert auf Qualität. Habt ihr Code-Reviews? "best programming practices", "programming paradigms", "improve code quality", ... Anonsten gibt es auch Bücher, wie z.B. "clean code". Am allerwichtigsten ist es dennoch, jemanden zu haben, der sagt: "das hier kannst du so und so besser machen" (deshalb meine Frage nach den Code-Reviews).

Ich würde das nicht auf die leichte Schulter nehmen (siehe z.B. folgenden Artikel: Medienaufseher beanstanden Streaming der Handball-WM). Am besten ihr fragt jemanden, der sich mit der rechtlichen Lage auskennt (z.B. einen Anwalt). Das wird zwar etwas kosten, aber ggf. ist das billiger als ein Bußgeld und evtl. bekommt ihr das als Verein günstiger (Stundensätze über 100€ sind bei Anwälten üblich).

"Gegen die Wand fahren lassen" heißt ja nicht unbedingt, dass das ganze Projekt scheitert. Das heißt erst mal nur, dass der TE die Verantwortung nicht haben sollte die er hat, da er diese weder in seiner Position als Entwickler haben sollte, noch in seiner Gehaltsklasse liegt. Auf jeden Fall muss der TE die Sache eskalieren, so dass von seiner Seite aus alles sauber ist. Wenn dann der Verantwortliche nicht reagiert, ist es nicht seine Schuld. Aber solange der Verantwortliche reagiert, ist das Projekt auch (noch) nicht in Gefahr. Ich zumindest habe ich die Erfahrung gemacht, dass Eskalationen erst mal nichts negatives sind, sondern manchmal sogar nötig sind, um Projekte erfolgreich abzuwickeln. Dazu muss natürlich eher früher als später eskaliert werden. Bei guten Arbeitgebern werden dann alle Projektbeteiligten in ein Eskalationsmeeting eingeladen, das Problem erörtert und eine Lösung gesucht. Wenn sowas in die Richtung nicht stattfindet, laufen grundsätzlich andere Sachen in der Firma schief. Ich sehe das grundsätzliche Problem in den verschiedenen Rollen des "Chefs". Auf der einen Seite, möchte er jedes Projekt annehmen und verkaufen, auf der anderen Seite sollte er als Personalverantwortlicher nicht sein Team verbrennen. Das ist eben ein Konflikt. Sind die Rollen getrennt, dann kann der Teamleiter sagen: "Moment mal, wir haben nicht die nötigen Kapazitäten dafür" und man muss auch mal einen Auftrag ablehnen oder kleiner stricken.

Ich würde mit sowas aufpassen. So wie ich das verstanden habe, hat dein Projektleiter (Chef) direkte Weisungsbefugnis dir gegenüber. Es ist immer eine ganz schlechte Idee, diesen zu sagen, was sie zu tun haben. Denn sie sehen das ja wohl anders (Er nimmt Projekt an, du machst das. Fertig). Wenn du nun Probleme darin siehst, dass ihr nicht die nötigen Ressourcen dazu habt bzw. du das Gefühl hast das nicht alleine bewältigen zu können, dann rede mit ihm. Aber nicht in Form von: "Du musst das und das machen" sondern in Form von: "ich brauche hierfür so und so lange, dafür ca. so lange, bis zur Deadline werden wir das nicht hinbekommen" und dann ist es in seiner Verantwortung, dafür Lösungen zu finden. Oder du arbeitest einfach deine vertraglich vereinbarten Stunden und gut ist es. Wenn dann das Projekt aufgrund von falscher Planung der Kapazität gegen die Wand fährt, ist es nicht dein Problem. Auch wenn du es nicht siehst, dein Chef bekommt nicht nur das Lob, sondern auch den Tadel und muss für das Projekt gerade stehen. Wie in den anderen Antworten bereits geschrieben wurde: das scheint doch gut zu funktionieren. Du hast dich also gewissermaßen selber in diese Position hineinmanövriert. Er weiß, er kann alles auf dich abwälzen weil du eben die Überstunden machst, um das Projekt zu ermöglichen. Für ihn funktioniert das, solange du da so mitmachst. Letztendlich liegt es dann an dir, daraus zu lernen und die Situation zu ändern oder ggf. dir eine neue Stelle zu suchen.

Ich denke, du kommst eben von dem einen Extrem in das andere Extrem. Ich kenne beide Extreme in der Form nicht, meistens war es bei meinen Arbeitgebern irgendwo dazwischen, also dass man sich zwar auch über Privates unterhalten hat und mal ein Bier trinken gegangen ist oder auch so seine Späße gemacht hat, aber dann auch wieder ein paar Stunden effektiv gearbeitet hat. Wobei das auch immer auf den Workload ankommt. Das hört sich für mich jetzt so an, als ob das Team (arbeitet ihr denn überhaupt im Team oder "jeder so vor sich hin"?) ziemlich unpersönlich ist. Dadurch ist ersichtlich, dass das Team noch nicht alle Teamphasen (einfach mal danach googeln) durchgemacht hat, also gar nicht entwickelt ist. In diesem Falle liegt es definitiv nicht an dir und du solltest aufhören, an dir wegen anderen Faktoren, die du nicht beeinflussen kannst, zu zweifeln.

Du kannst doch die Einheiten "Gewinn" und "Jährlicher Rückfluss" nicht durcheinander würfeln. Wenn du eine Einmalzahlung von 1500€ erhältst (was dann vermutlich auch Umsatz oder Einnahmen wäre und nicht Gewinn), ist die Amortisationsrechnung nicht das Richtige für dich. Die Amortisationsrechnung kannst du verwenden, wenn du hohe Anschaffungskosten hast, die über einen Zeitraum (zB. mehrere Monate oder Jahre) abgegolten werden. Bei deinem Fall hast du zwar Anschaffungskosten, aber einen einmaligen Verkauf.

Firebase Cloud Massaging ist was du suchst.

Ist aber auch nicht das selbe. Ersteres (instance.geProduct().setName(...)) sind zwei einfache Methoden, während letzteres (instance.Product.Name) zwei Properties sind (weshalb man sie auch groß schreiben sollte). Dadurch, dass es in Java keine Properties (in diesem Sinne) gibt und in C# Properties Setter und Getter haben, müssen in Java eben Methoden verwendet werden, um Setter und Getter zu implementieren. Wobei Java-Entwickler das gerne für jede Klassenvariable schreiben, egal ob der Setter und Getter noch irgendwelche besondere Logik enthält. Was nun besser ist, darüber kann man natürlich streiten. Ich finde hier C# etwas eleganter. Allgemein finde ich, dass C# ein paar schöne Konstrukte hat, die es in Java nicht gibt wie z.B. Extension Methods, Object Inititalizer und sicher noch ein paar Dinge mehr. Ich mach schon lange kein Java und C# mehr, deshalb kann ich dir gar kein so guten Rat darauf geben. Sprachlich schöner als Java und C# finde ich Swift (Apple) und Kotlin (Java Runtime), diese wären vielleicht noch ein Blick wert. Ansonsten kommt es, wie bereits gesagt, auch häufig auf das verwendete Framework an. Wie schwer war hier für dich der Umstieg bzw. wie lange hat es ungefähr gedauert? Die Denkweise ist ja dann doch eine andere. Ich spiele gerade auch mit dem Gedanken, mich mit Elixir auseinanderzusetzen.

Erst einmal hat Git mit der IDE nichts zu tun. Viele IDEs beinhalten zwar auch einen Git-Client, aber du kannst das auch per Kommandozeile nutzen, was ich erst einmal empfehlen würde, damit du verstehst wie das ganze funktioniert. Wenn du auf einen Button in einem Git-Client klickst, weißt du quasi nicht, was da im Hintergrund tatsächlich passiert. Einfach gesagt funktioniert es so, dass du Änderungen am Code erst commitest (git commit), dann sind deine Änderungen im lokalen Branch eingereicht. Damit die auch auf den Git-Server gelangen, pusht du die lokalen Commits auf den Server hoch (git push). Wenn du dich nun an einen anderen Rechner setzt, kann du die Änderungen herunterladen (git pull) und weiter dran arbeiten. Zu Empfehlen ist auch immer eine "Git Strategie". Davon gibt es mehrere, häufig verwendet man sogenannte Feature-Branches. Das heißt, jedes Feature (oder Bugfix) bekommt einen eigenen Branch, den du auch auf den Server pushen kannst. Nun gibt es mehrere Branches die du zusammenfügen (mergen) kannst, zum Beispiel Feature/X in den Masterbranch mergen. Meist schützt man den Masterbranch auch, so dass niemand ohne Review in den Masterbranch mergen kann. Wenn es Konflikte zwischen den Branches gibt (z.B. eine Datei wurde in zwei Branches verändert), müssen die Konflikte erst aufgelöst werden. Nicht ganz. Durch einen gemeinsamen Ordner hast du zwar die Dateien auf mehrere Rechner verteilt, aber du hast eben keine Versionsverwaltung, weil es logischerweise nur eine Version gibt. Der Vorteil an Git liegt eben darin, dass du viele Branches hast und dadurch jeder Entwickler unabhängig von den anderen in seinem Branch entwickeln kann, also ohne sich gegenseitig zu beeinträchtigen. Meiner Meinung gehören Git-Grundlagen zu den Grundlagen, die jeder Entwickler heutzutage beherrschen sollte. Ich selber verwende es inzwischen auch für private Projekte, auch wenn ich da alleine entwickle. /Edit: Eine "richtige" Versionsverwaltung hast du eigentlich erst, wenn du Continuous Integration (CI) betreibst. Hier wird nach dem Mergen in Master (oder bei getaggten Commits) die Software auf einem Server komplett zusammengebaut und erhält dadurch natürlich auch eine neue Version. Wenn man das auf die Palme bringt, kann man Software so gleichzeitig auch verteilen (Continuous Delivery, CD), zum Beispiel auf einem Server deployen oder in einen Appstore ausliefern.

Ich finde, es kommt drauf an, für was für eine Stelle du dich bewirbst. Wenn du dich z.B. als React-Frontend-Entwickler bewirbst, interessiert es niemanden, ob du Apache, IIS, Wordpress, C, PL/SQL, ... schon Mal gemacht hast. Genauso wenn du dich als Datenbank-Profi bewirbst ist Wordpress, HTML, usw. egal. Außerdem bin ich der Meinung, nur wenn man ein mal ein Apache oder IIS aufgesetzt hat, ist man darin noch lang kein Profi. Sich darin einarbeiten zu können, falls notwendig, ist für mich Voraussetzung an einen jeden ITler. Für mich sieht es auch so aus, als ob du eher Generalist statt Spezialist bist. Das wiederum heißt, dass du alles mal irgendwann irgendwo gemacht hast, aber nichts wirklich tiefgehend beherrscht. Das kann je nach Unternehmen vorteilhaft bei der Bewerbung sein (z.B. bei "Fullservice"-Agenturen), in der Regel aber eher ein Nachteil.

Ganz physikalisch: I: Stromstärke [A] = 16A (je nachdem was im Haushalt so alles angeschlossen ist, drüber fliegt die Sicherung raus) r: Radius [cm] = 1cm (also beide Kabel fast nebeneinander) Gesucht: H: Magnetische Feldstärke [A/m] H = I / (2Pi * r) H = 16A / (2*3,142 * 0,01m) H = 0,028 A/m Also macht es definitiv Sinn, wenn ein Lankabel neben einem Stromkabel abgeschirmt ist.

Mit wie vielen Gästen ist denn zu rechnen? Selbst wenn die Halle mit nur 20 Besuchern belegt ist, ist es mutig, sie alle gleichzeitig eine LTE-Verbindung nutzen zu lassen. Ansonsten wäre vielleicht Richtfunk zwischen Halle und dem nächstem Anschluss (ich geh mal davon aus, dass irgendwo auf dem Hof Internet verfügbar ist) die wohl bessere Möglichkeit.

Da ich zufällig aus dem App-Bereich komme: Sketch ist der Quasi-Branchenstandard (https://www.sketch.com/). Kostet aber 100$ im Jahr (für Studenten 50$). Eine Alternative ist, wie schon erwähnt wurde, das kostenlose Adobe Experience Design (XD), kann aber soweit ich weiß noch nicht ganz so viel. Für Sketch als auch für Adobe XD gibt Assets bzw. UI-Kits https://developer.apple.com/design/resources/ https://www.adobe.com/de/products/xd/resources.html#panel-3

Genau hier ist ja der Vorteil von agilen Methoden. Beim klassischen Wasserfallmodell stehen oben die Anforderungen und irgendwo unten die Porjektabnahme nach den Anforderungen. Bei kleinen Projekten auch kein Problem. Bei großen Projekten über mehrere Jahre hinweg ändern sich aber höchstwahrscheinlich die Anforderungen. Das heißt, was der Kunde bekommt ist zwar das was er ursprünglich wollte, aber nicht mehr das was er nun braucht. Und genau hier greifen solche Zyklen ein. Zurück zu deiner Frage: Ja, "Agilität" ist sicher in einem gewissen Maße gegeben, wobei man aus der Grafik nicht sieht nach welchen Methoden (XP, Scrum, ...). Es ist durchaus üblich, dass intern irgendwie agil entwickelt wird und nach außen zum Kunden klassisch. Das hat einmal den Grund, dass viele Auftraggeber gar nicht wissen, was agile Methoden überhaupt sind und wenn, dann ist für sie das höchste maß einen "Product Owner" zu benennen und zu denken, dadurch machen sie Scrum und sind wahnsinnig agil. Das ist auch OK so. "100% agil" findet man sowieso nirgends. Das hindert aber niemanden, intern trotzdem agil in Sprints zu entwickeln, Rollen zu definieren usw.

Letztendlich brauchst du eine Forschungsfrage, die du innerhalb der Thesis umfassend beantwortest. Die Forschungsfrage soll dabei nicht so gestellt werden, dass du diese mit "ja" oder "nein" beantworten kannst. Ob du die Forschungsfrage theoretisch bearbeitest oder praktisch, ist erst mal gar nicht der Punkt, denn das kommt eben auf die Forschungsfrage drauf an. Du solltest/musst aber wissenschaftliche Methoden anwenden. Das wäre ja ein Ansatz für eine Forschungsfrage: "In wie weit kann eine DR Planung generisch umgesetzt werden?". Und das dann an dem Beispiel/des Systems des Arbeitgebers. Letztendlich musst die Forschungsfrage aber mit den Betreuern (Betrieb und Uni/FH) besprechen.

Bei uns ist es so, dass wenn mir ein Kollege hilft oder ich einem helfe, dass die Zeit dann auch auf das Ticket bzw. Kostenstelle gebucht wird. Wie es dann die Rechnungsstellung macht, ist nicht mein oder sein Problem, die kann dann aber auf Kulanz weniger Stunden verrechnen als wir beide zusammen benötigt haben. Natürlich fragt auch der Projektleiter nach, wenn zu viele Stunden auf ein Ticket gebucht werden, meistens kann mans dann ja erklären.

"The growing cost of fixing bugs. The longer you wait, the more you’ll pay." (Quelle: http://www.developertesting.com/archives/month200501/20050127-TheDeveloperTestingParadox.html)

Ich kenne die Qualität der Kurse nicht, aber auf Blick auf Webstacks würde ich sagen: Grundlagen sind dabei (HTML, CSS, JavaScript). Die muss man einfach beherrschen Bootstrap ist nicht schlecht, wobei es auch das Lager gibt, dass Bootstrap dann doch nicht so viel Arbeit abnimmt, wenn man selber recht fit in CSS ist. Hier ist zu erkennen, dass umso erfahrener der Entwickler ist, umso weniger wird Bootstrap eingesetzt. Serverseitig: Mit "MongoDB for Beginners", "Express for Beginners" und "Create REST APIs with Express and MongoDB" lässt sich sicher was anfangen. Wobei ich auf längere Sicht dann doch eher andere Frameworks wie z.B. "NestJS" empfehle oder aber weg von Node. Clientseitig: Hier kann man sich entscheiden, ob man React ("Build Web Applications with React", "Intermediate React and Redux") oder Angular ("TypeScript for Beginners", "Learn Angular by Creating a Web Application") machen möchte. Beides sehr gut. Vielleicht noch interessant sind GraphQL (wird in Zukunft wichtiger werden) und evtl. irgendwann später auch die Deployment-Geschichten.

Das ist weil das ganze KI-Zeugs eben sehr theoretisch und mathematisch ist. Jedenfalls waren die KI-Vorlesungen bei uns reine Mathematik, weshalb ich sie nicht gewählt habe, wobei das Thema an sich sehr spannend ist. Andererseits haben auch andere sich in KI eingearbeitet, Modelle angelernt und damit bisschen in Python rumgebastelt, auch mit ganz guten Ergebnissen. Es ist eben immer eine Frage wo du hin willst: Willst du selber Algorithmen entwickeln, optimieren, verbessern oder willst du bestehende KI-Algorithmen/Programme anwenden? Künftig wird KI immer wichtiger, aber auch Hochschulen und Universitäten wissen das und richten Forschungslabore ein oder entwickeln sogar die ersten reinen KI-Studiengänge. Du musst dir eben im klaren sein, dass du vermutlich sehr gefragt bist wenn du dich mit KI auskennst, aber auch, dass du künftig innerhalb der nächsten 5 Jahre immer mehr gegen Akademiker konkurrieren wirst.

Bisher habe ich serverseitig noch nichts mit Swift gemacht, dafür halt iOS Apps. Swift ist an sich eine sehr gelungene Sprache. Ich z.B. befasse mich gerade gezwungenermaßen mit .NET Core, ist aber viel besser als ich dachte. Dafür habe ich mit Java EE, Spring Boot, Laravel und Node.JS (Express und NestJS) gearbeitet und sage mal so: das meiste können alle Frameworks "irgendwie". Für mich ist eine schöne Architektur wichtig (MVC oder MVVM), deshalb fliegt z.B. reines Express inzwischen raus. Letztendlich brauche ich wegen SPAs auch keine serverseitiges Rendering, wobei ich die SPAs mit Angular entwickel. Deswegen ist für mich NestJS momentan am interessantesten, weil die Architektur an die von Angular angelehnt ist. Wobei eben die Node-Dependencies echt eine Hölle sind. Also wenn es einfach nur um eine schöne Sprache geht: Swift ist super. Ein Blick auf Kotlin kann aber auch nicht schaden. Wenn du JS clientseitig verwendest, spricht auch nichts dagegen, das auch serverseitig zu verwenden. Im Grunde ist es bei Hobbyprojekten immer die Frage nach deiner persönlichen Präferenz. Ansonsten kannst du auch einen Blick in Richtung serverless wagen (Google Firebase, AWS Lambda, ...).

Es wird immer die Präsens verwendet. Auch Präsens: "Zur Pflege der neuen Daten wird ein [...] Programm erstellt." Kein "ist worden" / "folgte" / "wurde", sondern Präsens: Im Anschluss wird... / Anschließend wird... / Folgend wird... Darauf folgt... Nach XYZ wird... Es wird... Es folgt... ...

Aus meiner Erfahrung kann ich sagen, dass es Studenten mit einer 1 in "Grundlagen der Software Entwicklung" haben, die Modulprüfung aber absolut theoretisch war und die somit nicht einmal eine Schleife programmieren können. Dann gibt es die, die darin eine 3 haben, aber eigentlich sehr gut darin sind. Wie man an dem Beispiel sieht, sagt die Note also absolut nichts über das Können aus. Dann bei Projektarbeiten: da gibt es die, die das Projekt alleine machen und drei, die dabei zuschauen. Nachher haben oft alle die gleiche Note, obwohl unterschiedliches getan. Es kommt also auf den Einzelfall drauf an. Pauschal würde ich das so nicht sagen. Es gibt diejenigen, die einfach technisches Verständnis haben und denen das mega leicht fällt und deshalb sehr gute Noten haben. Dann gibt es die, bei denen das nicht so ist, die dafür aber Tag und Nacht lernen müssen und dann gibt es die, denen es auch nicht leicht fällt und die nicht so streng mit sich sind und dadurch eben nicht den 1er-Anspruch an sich haben. In jeder dieser Gruppe gibt es diejenigen mit mehr oder weniger Softskills. Dazu ist ein Studium ja auch nicht da. Ein Studium ist grundsätzlich reine Wissensvermittlung. Ein bisschen dient dafür vielleicht das Praxissemester. Auch wenn es uns über die Schulzeit ständig eingeredet wird, es kommt nicht nur auf die Noten an. Du hast dich eben gut verkauft. Das kann auch nicht jeder. Es muss letztendlich fachlich als auch persönlich stimmen. Fachlich kann man noch schrauben, persönlich ist es dann schon schwieriger. Die Relevanz richtet sich nach deinem persönlichen Anspruch. Gerade in der IT finden so gut wie alle einen Job, egal wie die Noten aussehen (bei meiner Hochschule haben 90% der Absolventen innerhalb der ersten drei Monate nach dem Studium einen Job. Und dazu zählen nicht nur IT-Studiengänge). Anders ist es, wenn du einen Master machen möchtest (bei meiner Hochschule lag hier der NC bei 1,7). Es gibt bei uns große Firmen, bei denen man sich ohne Master gar nicht bewerben braucht, einfach weil sie es sich durch die hohe Zahl der Bewerber leisten können. Dafür stimmt dann aber auch die Bezahlung.

Warum sind da Leerzeichen bei '_mm.yyyy'? Und was für ein Datentyp ist "zeit" und was für Inhalte hast du da?

Bei welcher IHK bist du? Hört sich nach der an, bei der ich war. Wir waren vier die verkürzt haben und alle haben schlechte Noten bekommen. Vor der mündlichen haben die Prüfer gemeckert, dass das Verkürzen nur mehr Arbeit für sie ist und man das abschaffen sollte, waren also bereits vor der Prüfung voreingenommen. Wir haben dann alle bestanden, aber wie gesagt, mit schlechten Noten. Würde mich nicht wundern, wenn es die gleichen Prüfer gewesen sind.

Mein Rat: belass es dabei, dass du die Prüfung bestanden hast. Warum? Bei mir was es ähnlich, die schriftlichen Prüfungen super, mündliche Prüfung versemmelt, warum auch immer (habe verkürzt, Prüfer waren mürrisch warum man überhaupt verkürzen kann, das ist nur mehr Arbeit für sie blabla. Es haben alle, die verkürzt haben, ne schlechte Note bekommen). Aber seis drum: interessiert jetzt auch keinen mehr. Hier im Forum beschweren sich immer wieder welche über die mündl. Prüfung und wollen Einspruch erheben / vor Gericht gehen / was auch immer. Ich denke mal, das Einzige was passieren könnte wäre die Prüfung ein halbes Jahr später zu wiederholen, ggf. mit den gleichen Prüfern. Na dann viel Spaß! Bietet eher mehr Nachteile als Vorteile.