azaziel

@alegermi Ich find es ist halt immer viel Lärm um nichts. Aus meiner Sicht ist Design Patterns als Buch einfach redundant und ein Paradebeispiel an Profanität. Erkenntnisse á la "Hallo Captain Einsicht". Sprachagnosis stirbt übrigens spätestens mit dem ersten Mnemonic. Aber das kann man mal an anderer Stelle ausdiskutieren Gerade Ausbildung hat ja nun auch noch ganz andere Schwerpunkte als nur Fachliches. Da geht einiges leider unter. Vielleicht eine Anregung für die Moderation. So ein paar angepinnte und gepflegte Literatur- und Referenzlisten als Übersicht für angehende FISIs/AEs wären für manchen sicherlich hilfreich.

Hi, Da haben Sie Dich ja eiskalt erwischt. Für das nächste Gespräch bist du gewarnt, lies dir das nochmal an und lass Dich nicht verunsichern. Das mit den Frameworks ist nicht so wild. Sag mit welchen Du bisher was gemacht hast und gib ruhig zu ,dass du dich erst einarbeiten musst. Du kommst frisch aus der Ausbildung, da kennt man noch nicht alles zu mal auch jedes Jahr eine neue Sau durchs Dorf getrieben wird. Design Patterns ist einfach nur javasprech für best practices. Sprich Klassen so schreiben, dass man sie vernünftig wiederverwenden kann. Scopes/Namespaces nicht kaputt spielen, ORM/Prepared Statements, Dekoratoren, saubere Implementierung von Interfaces, MVC Applikationsmodell, generics verwenden etc. bla bla..... Nicht jedes Pattern ist immer sinnvoll, am besten gönnst du dir mal ein Wochenende GIDF.de und liest Dich in Ruhe ein. Wenn du es erstmal in Code siehst merkst du schnell, dass das viel heiße Luft um nichts ist. Am Ende geht es nur ums Wording, der Rest ist ganz schlicht sauberes Java-OOP. Du solltest wissen was ein CRM tut und wofür es gut ist. Typische Projekt CRMs wären SugarCRM, MS Dynamics, Zoho Ansonsten - CRMS gibts wie Sand in der Wüste. Verkauft jeder größere Konzern - Sage, SAP, MS, Oracle, Salesforce oder IBM - da bekommst du bei allen was(und das sind nur die großen). Das ist eine Frage á la "welche Autos kennst du so". Für SQL solltet du dir zumindest trigger und functions/procedures anlesen. (sinnvollerweise für den SQL Dialekt auf den Du gelernt hast PL/SQL, Transact, PL/pgSQL whatever) Bin ein wenig erstaunt, dass das nicht bei Dir an der Berufsschule durchgenommen wurde. Grüsse Typisches Java Gedöns von dem man mal gehört haben sollte: Frameworks: Maven (SoftwareManagement/Build) Ant (SoftwareManagement/Build) JSF(WEB) FormEngine(WEB) Spring(MultiPurpose/Web) Struts(MultiPurpose/Web) Swing(GUI) JavaFX(GUI) Hadoop(BigData) Kafka(backend) Tomcat(backend / Java application server) Spark (BigData) Oracle Weblogic(backend / Java application server) SCM: git subversion mercurial Fullsize IDE: IntelliJ IDEA Eclipse IDE Netbeans debug: jdb btrace jmap/heapwalker/MAT JUnit/TestNG jpda

abend, @Errraddicator Ich bin recht trocken in meiner Art. Fand das gar nicht schwarzmalerisch. Ich mache öfter mal den technisch-fachlichen Teil bei Job-Interviews und ehrlich gesagt interessieren mich Berufspraxis und Vita des Menschen vor mir mehr als ein IHK Abschluss. Geschweige denn, dass ich Noten besondere Bedeutung beimessen würde(es sei denn sie sind so grottig, dass es einem direkt ins Auge springt). Abschlüsse und Zertifizierungen? 1.) Um nicht mehr durch die HR Filter zu rauschen, vorher bekommen Interviewer dich einfach nicht zu Gesicht. Personaler haben naturbedingt nicht das nötige Fachwissen für die fachlich korrekte Beurteilung von diversen Berufsgruppen. Die müssen ja nicht nur IT'ler einstellen. Ergo wird nach gegebenen Kriterien vorselektiert. Mit steigender Erfahrung des Personalers wird die Selektion natürlich zunehmend präziser. Personaler weiß dann immer noch nicht was ein C# oder rust im Detail ist, geschweige denn warum TCP besseres Benehmen als UDP hat. Aber man hat dann verstanden, dass das dev-team lieber gleich C# Entwickler statt umlernende Rust-Coder möchte. Höherwertige Zertifizierungen werden verlangt, weil unsereins auch solche Zettel hat und man damit zumindest grob vorsortieren kann. Sowas wie MSCA oder CCNA packst auch mit auswendig lernen, der beweist fachlich erstmal noch gar nichts. Bei höheren Certs sieht die Welt dann anders aus. Auf dem Level fragt auch ein Microsoft oder Cisco dann Detailwissen ab. Dafür musst du tatsächlich lernen - selbst wenn du auswendig lernst bleibt bei der Menge im Allgemeinen genug hängen für die meisten Jobs, der Rest ist Praxis. 2.) Der Bewerber beweist mit erfolgreichen Bestehen Ausdauer. Es findet sich mancher Grund um einfach hinzuschmeißen, hat man aber nicht. Good thing, isn't it?. 3.) Noten? Naja - eine Einschätzung vom Prüfer für den Prüfling darüber, wie gut die Aufgabenstellung nach deren Kriterien gelöst wurde. Kann man dran wachsen oder eben nicht. Man macht sich eigenes BIld, für den Rest gibt es die Probezeit. Warum man auf gute Prüfungsnoten, Certs und Abschlüsse hinarbeiten sollte? Variante für Pessimisten: Den Letzten beißen die Hunde. Variante für Optimisten: Niemand ist immer Erster, aber tritt man deshalb an um Zweiter zu werden? Grüsse

Das hat eigentlich weniger mit Produktvergleich zu tun sondern mehr mit Erfahrung. Kannst du Front- und Backend nicht sauber trennen, ist das grundsätzliche Design in Frage zu stellen. (sollte bei deiner Lösung* aber kein Problem sein). Ausserdem ist sowas immer gutes Bullshitbingo - gerade in so einem Projektantrag klingt das alles gleich viel wichtiger. und größer Davon mal abgesehen wird so eine Lösung nicht gut skalieren. Ob das nun klassische Serverdienste oder Microservices betrifft ist dabei unerheblich. Wenn sowas triviales nicht klappt kannst Du davon ausgehen, dass es nur die Spitze des Eisbergs darstellt. Die mangelnde Tiefe ergibt sich dadurch das ein erfahrener Admin sowas in kürzester Zeit hochzieht. Ich habs grad mal in der VM installiert - ~10 Minuten Basiseinrichtung. (ohne härten) Bei aller Liebe für Doku und Zettelei, so ein Projekt sollte wohl etwas mehr als ein bis zwei Stunden tatsächliches technisches Doing erfordern. Das ist gemeint mit mangelnde Tiefe. Die Sache ist die, haben Deine Prüfer gute Laune kommst Du damit vielleicht durch. Haben sie schlechte Laune, dann lassen sie Dich eventuell eiskalt auflaufen, Du stehst dumm da und der ganze Aufwand war für die Katz. Motz das ganze mit Scripten/Plugins auf oder härte das System zusätzlich und dokumentiere es. Irgendwas, das Deine Handschrift trägt und at least mehr Aufwand suggeriert als nur mal fix eine Software zu installieren. *GLPI

Bei ~250 Usern hängt das eher von der Last des MS-SQL Servers ab. Ausgehend von sagen wir mal 10 Vollzeitnutzern und einer geschätzten Problemrate von rund 15/100 Usern hätten wir eine durchschnittliche User-Rate von 35-45 Usern (ohne Peaks bei massiven Problemen). Dazu müsstet ihr aber schon ziemlich lausig sein. Realistischer wären vermutlich 5-10%(einschliesslich typischer Layer8 Issues), das wären dann ca 10-25 User zeitgleich. Die Last für die MariaDB/MySQL Instanz ist da vernachlässigbar. Achtung - das gilt nicht zwingend für den Apachen der das PHP ausführt. (kommt auf die Code-Qualität der Anwendung und den genutzten Funktionsumfang an) Allerdings muss der Apache auch nicht zwingend in der selben Instanz/VM wie die DB laufen. (in größeren Setups sind Frontend und MW/BE sowieso getrennt untergebracht)

Das selbe mit mehr Geld wäre Projektmanagement. Mach nen Scrum Master oder sowas und werde Projektoberguffel.

In punkto Datenbank könntest Du zum Beispiel mit Optimierungen glänzen und dem Ganzen dadurch ein wenig Würze und Tiefe verleihen(in-memory tables für häufige reads anstatt permanenter queries auf die HDD; sql-trigger, functions & prepared statements an Stelle von direkten Queries etc. pp). Die Anforderungen die du da gerne in einem System hättest wirst Du leider so nicht finden. Da vermischen sich DCIM, IPAM, CMDB, EAM, ERP, DMS und weiss der Fuchs was nicht alles. Du suchst die eierlegende Wollmilchsau. Fokussiere Dich aufs Wesentliche sonst zerreibst Du Dich und Dein Projekt. MS-SQL kostet m.W. spätestens im Produktivbetrieb. Ich glaube die Wahl von Postgres oder Mariadb anstelle von MS-SQL könnte deine Auswahlmöglichkeiten deutlich erhöhen. Das alles läuft übrigens auch auf Windows ebenso wie der Apache. Du brauchst dafür also nicht zwingend eine Linux Maschine als Unterbau (obwohl sich das aus diversen Gründen empfehlen könnte). MS-SQL ist außerhalb der .Net-Welt freundlich gesagt exotisch. Jedenfalls sind MariaDB/PostgreSQL nicht anspruchsvoller als MS-SQL und grafische Frontends gibt es da ebenfalls. Es ist auch keine Schande so etwas zusammenzuklicken. In der Wirtschaft interessiert es wie produktiv Du bist und nicht wie "nerdig" Deine Lösung ist. Das verstehen deine Manager/Chefs im allgemeinen sowieso nicht und wissen es demzufolge auch selten zu würdigen. Was sie zu würdigen wissen sind schnell und sauber abgelieferte Projekte die am besten kein Geld kosten aber viel einbringen. Ergo: Dauert es länger als auf der cli ist es schlecht, geht es schneller ist es gut. Der ICH-Bezug(falls Du den so verwendest) muss definitiv weg. Projektbeschreibungen handeln vom Projekt und nicht von den Leuten die es durchführen. Das ist weder Autobiografie/Lebenslauf noch Bewerbungsanschreiben Bei uns laufen "ideale" Projekte grob nach diesem Schema ab: Anforderungsspezifikation Solution Proposal Aufwandseinschätzung Angebotserstellung (bei Zuschlag:) Design & Solution Documents Project Risk & Issue Analysis Projekt- und Arbeitspläne Changemanagement- und Implementation-Pläne Compliance Pläne (healthchecks, auditing/monitoring, DSVGO/BDSG Konformität) disasterrecovery & backup Pläne Testpläne Implementierung Testphase Erstellung technischer Dokumentation(funktional, technisch, handbuch) Übergabe & Schulung Die Prüfungsanforderungen der IHK können da teilweise abweichen(vermutlich nicht ganz so umfangreich, dafür weit mehr Focus auf ein klassisches Lasten-/Pflichtenheft). Der eine oder andere Fach-Informatiker hier im Forum kann dazu bestimmt wertvolle Hinweise geben. Ansonsten konsultierst Du da deinen Ausbilder am besten noch mal kurzfristig.

versuchs mal mit psinfo findest du bei microsoft auf der HP unter windows sysinternals.

Das sollte eigentlich so nicht demotivierend rüberkommen. Beiß Dich durch. Es wird nicht leicht, aber es ist auch nicht unmöglich. Alter bringt nicht nur Nachteile. Funfact: wir stellen in der Technik auch niemanden unter 30 ein, da fehlt den Leuten meist noch die Ruhe.Die kommt durch Erfahrung und zwar nicht technische sondern durch Lebenserfahrung. Bei deinem Alter behaupte ich mal davon hast du mehr als reichlich. Stell was interessantes auf die Beine und vernetze Dich. Vitamin B ist nach wie vor ein guter Helfer und hat schon so manchem angeblich "hoffnungslosen" Fall eben doch die ach so unerreichbaren Türen geöffnet.

Dann benutzt du sie falsch. Falsch: Antworten stupide auswendig lernen. Richtig: Schau dir die Antworten an und erkläre warum die Antwort richtig ist. Dann sind braindumps nützlich und es bleibt echtes Wissen hängen. Mausschubser gibt es wie Sand am Meer. Da bist du einer von vielen, dementsprechend lausig meistens die Bezahlung. Das "allgemeine Verständnis" von Netzwerken nutzt dir auch nur bei KMUs, größere Firmen haben dafür Spezialisten.(die "allgemeines Verständnis" zu Recht übrigens so gar nicht ernst nehmen) MSCA ist quasi das Windows-Seepferden, wie der CCNA/RS bei cisco oder sowas - sprich eigentlich nur eine Eignungsprüfung dafür, dass man die richtigen Prüfungen machen darf. Kannst ruhig bei Microsoft Certs bleiben, wenn Windows dein Ding ist, aber spezialisiere Dich. Entscheide Dich wohin die Reise gehen soll und arbeite auf den entsprechenden MSCE zu. Desktop Infrastructure, Server Infrastructure, Cloud, da gibt es etliche Möglichkeiten. MSCA an sich haut leider niemanden vom Hocker. Hast du den Fuß dann erstmal in der Tür kannst du immer noch sagen: "och windows ist bleh, ich möcht doch lieber DBA, Netzwerker oder Linuxer oder weiss der Deibel was werden" Dann hast du zumindest schon ein bisschen IT-Background erarbeitet und schon Erfahrungen gemacht. Ab MSCE rauschst du auch nicht mehr so leicht durch die Filter der HR'ler Zu mal mehr als den eigenen Tellerrand zu kennen dann sogar wieder von Vorteil ist.

Moin! Das Problem ist, die Ausbildung ist erst der Anfang. Damit kann man seltenst etwas direkt anfangen, wenn man aus einer Umschulung kommt. Wenn wir jemanden frisch einstellen kalkulieren wir mit 1- 1 1/2 Jahren bis derjenige dann tatsächlich alleine "laufen" kann und darf. Außerdem kann man keinerlei praktische Erfahrung vorweisen Die haben zwar Azubis und oder frische FI/AEs auch noch nicht wirklich, aber bei 20-30 Jährigen lohnt sich die Investition sie einzulernen, bei jemanden der in 5-10 Jahren in die Rente verschwindet ist das kaum wirtschaftlich. Programmieren heißt ja nicht nur Syntax sondern vertiefte Kenntnisse der Besonderheiten der jeweiligen Sprache und ihre Frameworks und Libs. Es bedeutet Prozesse in der entsprechenden Logik modellieren, abzubilden und dokumentieren zu können. Kurzum nach der Ausbildung beginnt das richtige Lernen. Will heißen, wenn Du da nach der Ausbildung einen Job willst brauchst du einen Bonus der dich trotzdem attraktiv macht. Als AE könnte das Mitarbeit an einem OSS Projekt oder parallel ein eigenes Projekt sein. Sinnvollerweise eins, das auch kommerziell interessant ist. Außerdem solltest du dich dann eher an kleinere Firmen halten. In großen Firmen sieht das eher mau aus, weil die HR alles vorfiltert und deine Bewerbung in Ablage P verschwindet bevor du überhaupt eine Chance hattest, da müsstest du schon der neue Stern am Softwarehimmel sein, damit sie sich trotzdem für dich interessieren. Kleinere Butzen sind da meiner Erfahrung nach offener -> Nachteil = das Gehalt ist meistens niedriger.