Goulasz

Hallo Welt! Nach einer längeren Zeit der Beitragsflaute mal wieder ein neuer Post. Dafür gibt es dieses mal auch etwas mehr und wieder einen Veranstaltungsbericht. Dieses mal jedoch nicht von einer Konferenz, sondern von einem Seminar mit anschließender Prüfung zur Zertifizierung. Vom 05.07.2016 bis zum 07.07.2016 bin ich mit einem Kollegen in Köln auf einer prüfungsvorbereitenden Schulung zum Thema "Usability Engineering and User Experience" gewesen und habe dort einiges an Wissen erworben, das ich gerne auszugsweise(da sonst jeglichen Rahmen sprengend) mit euch teilen möchte. Innovative Software braucht doch keine Kreativität "UX aus der Dose" Im April 2016 habe ich mit zwei Kollegen die "OBJEKTspektrum information days" in Frankfurt am Main besucht und dort einen extrem interessanten Vortrag von einem mir recht sympathischen Sprecher gesehen. In dem Vortrag mit dem provokanten Titel "Innovative Software braucht doch keine Kreativität – Ein Usability-Engineering How-to-Guide" beschrieb der Sprecher Herr Thomas Geis, wie man mithilfe der EN ISO 9241 und anderer Erkenntnisse aus dem Bereich "Entwicklung gebrauchstauglicher Produkte" mit rein methodischem Vorgehen sogenannte "Erfordernisse" an ein Produkt identifizieren kann, die unabhängig von bisherigen Lösungen oder Anforderungen oft exakt das beschreiben, was eigentlich vom Benutzer gewünscht wird. Beispiel gefällig? Heizungsventile kennt ja so ziemlich jeder. Üblicherweise sind die irgendwie zum Drehen und haben von 0-5 eine Skala drauf, wobei man eigentlich nie weiß, welche Zahl welche Temperatur bedeutet. < Ein beliebiges Standard-Thermostat Ein Erfordernis an ein Heizungsventil oder eine "Heizeinrichtung" allgemein lautet jedoch eher so: "Der Benutzer muss wissen, welchen Wert er eingeben muss um eine gewünschte Raumtemperatur zu erreichen." Daraus ergibt sich, wenn man genau ist, nicht die Anforderung "Der Benutzer muss am System an einem Drehregler einen Wert von 0-5 einstellen können", sondern eher etwas wie "Der Benutzer muss am System die gewünschte Zieltemperatur eingeben können." Was passiert, wenn man so eine Anforderung konsequent zu einem sogenannten "interaktiven System" weiterentwickelt, sieht man beispielhaft hier. Das System ist bezüglich der Temperaturmessung im Raum zwar noch nicht zu 100% ausgereift, aber ein gefühlter Quantensprung an "Mehrkontrolle" gegenüber einem regulären Heizungsventil. Denn sind wir mal ehrlich, wer kennt die Situationen nicht, in denen man wie ein Verrückter zwischen "2.5" und "4.5" am Heizungsventil hin- und herdreht. Noch spannender wird es, wenn man den Nutzungskontext einer "Heizung" genauer analysiert. Dann stellt man schnell fest, dass es nicht darum geht, eine "Zieltemperatur einzustellen", sondern dass es "angenehm temperiert ist". Analysiert man diesen Gedanken weiter, könnte es z.B. mit einem "Wearable Computer" verbinden um anhand der Körpertemperatur und der Entfernung zum Haus die Heizung so anzuschalten, dass die Wunschtemperatur immer automatisch gehalten wird. Fahre ich also weg, fährt die Heizung so weit herunter, dass sie, wenn ich jetzt umdrehen würde, bei der Ankunft zu Hause wieder auf der "Wohlfühltemperatur" steht. Boom! Innovation. Etwas, das als neu oder mit "Wow"-Effekt wahrgenommen wird, weil es bestehende Prozesse drastisch vereinfacht, verbessert oder einfach völlig anders löst als bisher bekannt. Das Seminar - "Usability in a nutshell" Angefixt von dem Talk auf der Konferenz haben mein Kollege und ich uns also ein gutes halbes Jahr später im Mietwagen nach Richtung Köln auf den Weg gemacht. Dadurch, dass der Talk auf der Konferenz so gut war, haben wir uns auch direkt dazu entschieden, das Training ebenfalls bei Herrn Geis von der Firma ProContext durchzuführen. Bevor jemand fragt, ich kassiere hier keine Provision, ich bin einfach wirklich begeistert von den Inhalten und der Art der Vermittlung. "Human centered design process" Nach dem Check-In im B&B-Hotel Köln/Messe und einem sehr geschmeidigen Abendessen in einem mexikanischen Restaurant ging es am nächsten Morgen ausgeschlafen und frisch gestärkt mit dem Zug Richtung Innenstadt zum Konferenzhotel direkt am Kölner Dom. Tag 1 - Usability-Basics Bevor in tatsächliche Übungen eingestiegen werden konnte, gab es erstmal eine ordentliche Portion Theorie. Denn bei der Herstellung gebrauchstauglicher Produkte gibt es eine Menge Dinge, die einem begegnen können, die sehr präzise eingeordnet werden müssen, um sie richtig zu deuten. Die ISO-9241 und die Seminarinhalte vermitteln uns genau diese Sprache, diese Begriffe mit denen es möglich ist, solche Themen und diffusen Konzepte konkret zu benennen und damit zu arbeiten. Programmübersicht Tag 1 Themen waren unter anderem "Erfordernisse", "Anforderungen" und was deren Unterschied ist. Ein Erfordernis z.B. ist oft unbewusst, ein sogenanntes "implied need" und muss systematisch im Nutzungskontext erhoben werden. Eine Anforderung wiederum befriedigt bei Erfüllung ein Erfordernis und basiert auf diesem. An 2 Beispielen möchte ich das kurz exemplarisch für andere erläuterte Begriffe darlegen. Alles ausführen kann und möchte ich hier nicht, das würde a) den Rahmen sprengen und müsste ich euch das vermutlich beim Lesen in Rechnung stellen. Erfordernis Syntax: Die <Benutzergruppe>, muss XXX wissen / verfügbar haben, um YYY entscheiden / tun zu können. Es gibt also immer eine Voraussetzung und einen Zweck, die im Erfordernis festgehalten sind, welches wiederum im Nutzungskontext verankert sein muss. Ein Beispiel für eine Vorrichtung zum Garen von Eiern: Der Benutzer muss den Garzustand des Eis kennen, um entscheiden zu können, ob er es im Garvorgang belässt oder nicht. Anforderung Syntax: Der Benutzer muss am System ZZZ erkennen/überblicken können auswählen können eingeben können Daraus ergäbe sich für unsere Garvorrichtung folgende beispielhafte Anforderung: Der Benutzer muss am System den Garzustand der darin befindlichen Eier erkennen können. Wie diese Anforderung jetzt technisch umgesetzt wird, ist an dieser Stelle bewusst offen gehalten. Ob eine grafische Anzeige, eine Push-Mitteilung auf das Smartphone (IoT ist ja in aller Munde momentan), eine Melodie oder was auch immer das "Beste" ist, wird im Anschluss im Test überprüft. Des weiteren wurden die 7 Dialogprinzipien und ihren Auswirkungen auf die Gestaltung von Nutzungsschnittstellen thematisiert. Am Ende des ersten Workshop-Tages wurden gemeinsam in Übungen aus Nutzungskontextbeschreibungen Erfordernisse und aufbauend darauf Anforderungen her- bzw. abgeleitet. Interviews und Nutzerbeobachtungen spielen dabei im Vorfeld eine entscheidende Rolle. Der Tag war also schon gefüllt mit ordentlich Inhalt, sowohl qualitativ als auch quantitativ. Und es zeichnete sich nicht ab, dass das weniger werden sollte. Im Gegenteil. Um die Inhalte gebührend zu verarbeiten und Platz für Neues zu machen, gönnten wir uns mit einem Teil der Truppe nach einem Besuch des Weihnachtsmarktes am Kölner Dom gemeinsam im "Früh am Dom" noch das ein oder andere Kölsch. Tag 2 - Entwickeln und Testen von UI/UX-Lösungen “If the user can’t use it, it doesn’t work” –Susan Dray Noch leicht schwammig im Kopf vom Kölsch ging es mit der Bahn zurück zum Hauptbahnhof und von da aus ins Schulungshotel. Wenn Tag 1 den Fokus darauf legte, die Basis zu legen und Erfordernisse und Anforderungen zu sammeln, war der Hauptinhalt von Tag 2, zu erkunden, wie man dieses Wissen jetzt in ein Produkt, oder besser, einen Prototypen bzw. eine evaluierbare Geschäftsidee überführt. Der oben schon verlinkte "Menschzentrierte Prozess zur Gestaltung gebrauchstauglicher interaktiver Systeme" war die Basis, auf der der zweite Tag basierte. Nachdem man Erfordernisse identifiziert und Anforderungen hergeleitet hat, ist der nächste Schritt im Prozess, eine Designlösung zur Evaluierung zu erarbeiten. Auf gut deutsch: "Einen Prototypen zum Testen bauen." Dafür gibt es natürlich verschiedene Dinge, die man beachten muss. Ein paar Begriffe, Konzepte und Informationen, die dazu gehören, will ich hier exemplarisch auflisten. Kippschalter - Benutzung offensichtlich Affordance -Aufforderungscharakter Der Grad der Affordance beschreibt, wie sehr ein Element in einer Nutzungsschnittstelle zu seinem korrekten Gebrauch auffordert. Einem Schalter ist z.B. recht deutlich anzusehen, dass man ihn umlegen kann. Ich habe allerdings auch schon Dimmschalter gesehen, die man zum Anschalten nach unten "streicheln" musste und zum Abschalten bzw. dimmen nach oben. Aus Usability-Sicht ein ziemlicher Griff ins Klo. Intuitiv Im Usability-Sprech spricht man von Intuitivität, wenn die Benutzung eines interaktiven Systems unabhängig von der Erfahrung, vom Wissen, von den Sprachkenntnissen und dem momentanten Konzentrationsgrad des Benutzers unmittelbar verständlich ist. Das heißt in der Praxis, dass ein Geldautomat dann intuitiv ist, wenn man ihn am Ballermann als 16-Jähriger, der zum zweiten mal in seinem Leben Geld abhebt, grade bierbedingt 2,5 Promille intus hat trotzdem bedienen kann. Obwohl der Automat grade in "Spanisch" eingestellt ist. Leichter gesagt als getan also. Mentales Modell Unter einem "Mentalen Modell" versteht man die Vorstellung, die ein Mensch von der Umgebung, den Menschen und Dingen hat, mit denen er interagiert. Wasserhahn mit klassischer "blau - kalt, rot - warm"-Färbung Das Mentale Modell von einem Wasserhahn ist bei den meisten Menschen so konzipiert, dass es einen Griff zum Starten des Wasserflusses und einen Schieberegler zum Einstellen der Temperatur gibt. Das wäre das "Systemmodell". Ein Mensch, der zum ersten mal einen Wasserhahn mit Berührungssensor benutzen möchte, wird vermutlich Probleme damit haben, wenn er bis dahin noch keinen Kontakt zu dieser Technik hatte. Ein paar Jahre vorher gab es z.B. noch nicht mal den stufenloser Schieberegler am Mischer. So musste man noch manuell heißes bzw. kaltes Wasser aufdrehen, bis man die gewünschte Zieltemperatur erreicht hat. Moderne Systeme bieten hier (zumindest in der Dusche) oft schon eine auf den Regelmechanismus geätzte Temperaturskala an, die die Benutzung erleichtert. Wichtig ist für das mentale Modell jedoch diese Aussage. Passen mentales Modell und Systemmodell nicht zusammen, sind Nutzungsprobleme vorprogrammiert. Joel Spolsky, Gründer von Trello und Mitgründer von Stack Exchange, hat dazu vor 17 Jahren(!) einen Blogpost geschrieben, der immer noch Relevanz hat. Neben diesen Konzepten wurde den "7 Dialogprinzipien" an diesem Tag erneut verstärkt Zeit gewidmet. Dazu habe ich in meinem letzten Blogbeitrag aber schon ausführlich etwas geschrieben. Ein weiteres Thema waren verschiedene Gestaltungsrichtlinien, sogenannte "Styleguides" oder "Design Patterns". Hierbei handelt es sich um Vorgaben, wie z.B. ein Button, eine Tabelle oder der gesamte Checkout Vorgang in einer Webseite (das wäre ein Design Pattern) aussehen sollte. Die meisten großen Hersteller von Software bieten so etwas übrigens an. Auf der Homepage unseres Trainingsanbieters findet ihr dazu einer super Übersicht. Nach einer kurzen Exkursion zur Gestaltung verschiedener Prototypen (z.B. Papierskizze, Storyboard, Wireframe, etc.) ging es zum Ende hin dann zum großen Thema "Evaluierung der Designlösungen", also dem Test der Prototypen. Diesem Kapitel, das unter anderem Fokusgruppen, Benutzerbefragungen und Usability Tests beinhaltet, werde ich mich aber aufgrund des Umfangs in einem gesonderten Blogbeitrag widmen. Wir schlossen den Tag mit einer Übersicht über die verschiedenen Rollen im Usability Engineering Prozess, ein paar Übungsaufgaben und einem prall gefüllten Kopf für den morgigen Prüfungstag. Tag 3 - Prüfung zur Zertifizierung zum "UXQB® Certified Professional for Usability and User Experience – Foundation Level (CPUX-F)" Den Vormittag und den ersten Teil des Nachmittags wendeten wir am Mittwoch zur Aufarbeitung der Inhalte zum Überprüfen der Gestaltungslösungen (also Usability Testing und co.) auf. Am Nachmittag wurde es dann spannend. Die Prüfung stand an. Dazu folgende Rahmenbedingungen. 40 Fragen Zum Bestehen müssen 28 von 40 Punkten erreicht werden (70%) 75 Minuten Keine Hilfsmittel erlaubt Jede Frage hat 6 Antwortmöglichkeiten, bei denen eine "signifikant richtiger" ist als die anderen Gibt es nur eine richtige Antwort, gibt es einen Punkt für eine richtige und null Punkte für eine falsche Antwort Manche Fragen haben 2 oder 3 "signifikant richtigere" Antworten, wenn dies der Fall ist, geht es aber aus der Aufgabe deutlich hervor Gibt es mehrere richtige Antwortmöglichkeiten, gibt es für jede richtige Antwort 1/AnzahlMöglichkeiten Punkte. Für jede falsche Antwort gibt es 1/AnzahlMöglichkeiten Punkte Abzug. Die Gesamtpunktzahl kann aber nie negativ sein. Die Fragen wurden, soweit ich das beurteilen kann allesamt durch die Übungen und Beispiele im Training im Vorfeld abgedeckt. So habe ich es dann auch geschafft, stolze 87,50% zu erreichen. Die Schwierigkeit der Fragen war allerdings stark gemischt. So gab es von relativ einfachen Fragen wie "Bei welchen der folgenden Begriffe handelt es sich um Dialogprinzipien?", wo die Lösung einfach aufgrund der Namen recht simpel war bis hin zu sehr schwierigen Fragen, wo mehrere Lösungen tatsächlich richtig waren, aber eine eben ein "Stückchen richtiger" als die anderen eine große Durchmischung. Da ging es z.B. um eine Fehlermeldung in Form eines Fehlercodes nach einer Datumseingabe in einer Webseite und einen Vorschlag zur Verbesserung. Gegeben waren von der ausführlicheren Fehlermeldung hin zum "Tutorial" verschiedene Möglichkeiten. Die richtige war jedoch, die Datumseingabe durch eine Datumsauswahl zu ersetzen, um Tippfehler, die erst validiert werden müssen überflüssig zu machen. So einfach kann's gehen. Alles in allem machbar, aber knackig. Fazit Meiner Meinung nach waren das drei sehr gelungene Tage und wohl investiertes Geld. Geld heißt hier 1.500€ zzgl. MwSt. für das Training und 300€ zzgl. MwSt. für die Prüfung. Eine Rückerstattung bei Nicht Bestehen gibt es hier selbstverständlich nicht. Obwohl die Möglichkeit besteht, sich extern auf die Prüfung vorzubereiten und die Unterlagen dafür im Internet frei verfügbar sind, halte ich ein vorbereitendes Training für sehr wertvoll, um das Wissen im Kontext richtig einordnen zu können. Darüberhinaus hat man durch den Kontakt mit anderen Teilnehmern die Möglichkeit, sich über Praxiswissen und echte Anwendungsfälle direkt austauschen zu können, was in der Gruppe sehr wichtig war. Ich gucke heute noch regelmäßig in meine Schulungsmappe und das im Training bzw. für die Prüfung erworbene Seminar hilft mir tatsächlich, im Alltag bessere Entscheidungen zu treffen, wenn es um Produkt- oder Prozessgestaltung geht. Und da ist egal, ob es sich um digitale Produkte handelt oder "welche zum Anfassen". Wenn ihr Fragen habt, zögert nicht, hier zu kommentieren oder mir zu schreiben. Gruß, euer "devopsdad" Patrick

Einfach weil er gut ist, hier der Diablo Player's Guide to Path of Exile. Entnommen aus dem offiziellen PoE-Wiki am 21.08.2017 um 09:12. Wer Fragen hat oder mit den englischen Begriffen nicht klar kommt, meldet euch. Gruß, Goulasz

Moin moin! Über 3 Jahre seit dem letzten Post sind her und es hat sich viel getan in Wraeclast. Mein Inventar ist allerdings immer noch sauber aufgeräumt. Nicht zuletzt dank der Premium Currency und Essence Stash Tabs, die ich mir mal gegönnt habe. Das neue Content-Update "Fall of Oriath" (3.0) brachte einige sehr geschmeidige Neuerungen mit sich. Die wohl größte: Es gibt keine Schwierigkeitsgrade mehr. Statt in "Normal", "Cruel" und "Merciless" drei mal alle vier Akte spielen zu müssen gibt es jetzt ein einziges Playthrough der Story in zehn (ja, zehn) Akten. Danach geht es wie gewohnt ins Map-Endgame mit dem Atlas of Worlds. Für Einsteiger gibt es jetzt auch ingame-Tutorials, die die Grundprinzipien des Spiels sehr gut erläutern. Falls sich das jemand mal angucken möchte und ggfs. ein bisschen ingame schnacken mag, mein IGN ist "Thavian" und ich bin, wenn ich denn online bin, zwischen 20:30 und 24:00 mehr oder weniger verfügbar. Gruß, Goulasz

Hallo @bigvic! So war das auch nicht gemeint. Da habe ich den Punkt "allgemeine Chancen nur mit einem Studium" und "Chancen im Vergleich zu relevanten Ausbildungen" sprachlich vermischt, das tut mir leid. Ich wollte mit der Aussage auch darauf hinweisen, dass irgend ein Studium selbst beileibe keine Garantie für einen Job ist. Geschweige denn den "Wunschjob". Wobei ich allgemein bezweifle, dass jemand, der nicht schon sehr früh weiß, was er/sie möchte, nach G8 und dem Bachelor mit Anfang 20 genaue Vorstellungen hat, was er/sie beruflich machen möchte. Für den zweiten Fall stelle ich mir dennoch die Frage: Wo zieht man die Grenze der Relevanz für eine Stelle? Dazu ein Beispiel: Folgende Situation. Projektleitungsstelle ausgeschrieben, keine Personalverantwortung. 250.000€ Budget. IT-Projekt. Auftragsentwicklung Web-Anwendung. Person 1: FIAE-Azubi, 2 Jahre BE als Entwickler_in, hat schon in mehreren Projekten mitgearbeitet, aber noch keins geleitet, überschaubare Erfahrung im wirtschaftlichen Bereich, aber technische Expertise vorhanden. Person 2: BSc WiWi-Student_in, 2 Jahre BE im Controlling, hat schon in mehreren Projekten mitgearbeitet, aber noch keins geleitet, überschaubare Erfahrung im technischen Bereich, aber wirtschaftliche Expertise vorhanden. Ist das noch "relevant"? Wem würdest du den Vorzug geben? Oder würdest du beide einladen und es vom persönlichen Eindruck bzw. einer Kostprobe abhängig machen? Ich finde sowas allgemein schwer. Am "perfektesten" wäre vermutlich ein_e Wirtschaftsinformatiker_in mit Erfahrung in mehreren Projekten in Leitungsposition, aber wie es in der Realität mit passendem Fachpersonal aussieht, wissen wir alle. Wäre ich in der Position, die Stelle zu besetzen, ich würde beide einladen. Gruß, Goulasz P.S.: Ich möchte vermeiden, eine gar so konstruierte Situation zu bieten. Wenn jemand ein besseres Beispiel als meins hat, bitte. Immer her damit.

@bigvic Ich sehe das tatsächlich etwas anders. Wenn überhaupt, würde ich den Satz eher so formulieren: "Ohne einen guten Abschluss in einem in der Wirtschaft anerkannten Studiengang wird es zukünftig schwere einen Job zu finden" Mit nem 3.x in [Hier einen für euch absurd unsinnigen Studiengang einsetzen] wirst du auch gegen einen Azubi mit eher relevanter Ausbildung (hoffentlich) "verlieren". Ich habe im Deutschlandfunk dazu neulich übrigens eine Radiosendung gehört, wo es um die stetig steigende Anzahl an Promotionen geht und darum, dass neue Maßnahmen her müssen, um den Qualitätsanspruch an einen Doktoranden und seine Promotion zu gewährleisten. Ein ähnliches Problem. Die Frage, die ich mir stelle, ist nur: Wo soll das hinführen? Wird dann irgendwann für eine "simple" Projektmanager-Stelle ein Doktortitel verlangt? Und ist ein Azubi, der als Entwickler schon mal in einem SCRUM-Team gearbeitet hat, das agile Manifest samt Haltung dahinter verstanden und verinnerlicht hat, und die Rollen kennt, nicht sogar besser als Lead für ein Projekt in einem dynamischen, komplexen, schlecht planbaren Umfeld gearbeitet als jemand Studiertes, der nur PRINCE2 kennt? Meine Annahme (und ein bisschen Hoffnung) ist, dass sich die Wirtschafts- bzw. Bildungspolitik dahingehend wandeln wird, entweder die Inhalte in Studiengängen zu reformieren und relevanter in die Realität zu bringen oder die Recruitingverfahren weniger über reine statistische Datenauswertung laufen zu lassen. Gruß, Goulasz

Absender: xXAlliDestroyer94Xx@web.de Betreff: Bewerung hallo i bims 1 nicer bewerber vong umschulung her, i han 1 info gereadet über euer übernices company und wollte da mitmachen vong arbeit her. i hans viel erfahrung mit computern vong lan-party und schule her. wenn i bei euch bims, spreade ich das word von euch als coole company, sicher! greetz, Alli Anhänge: Lebenslauf_alt_final.xlsx amschreiben_deckblatt_HierFirmaEinsetzen.docx zeugnis.tiff

Guten Morgen in die Runde! @Gurki Formal liegen sowohl der OP als auch der Bachelor im DQR beide auf Level 6. Wenn es nur darum geht. Was es aber in der Praxis glaube ich oft leider nicht tut. Oft hilft aber auch einfach "machen und fragen". Also in bestehenden Positionen andere Rollen einnehmen. Z.B. für ein internes, überschaubares Projekt mal den Product Owner oder Scrum Master machen. Wenn man weiß, was man möchte und ein verständisvolles Umfeld hat, steht man sich oft eigentlich nur selbst im Weg. Dazu gehört aber zum einen, zu wissen und vor allem formulieren zu können, was man möchte, und zum anderen, auf Gesprächspartner zu treffen, bei denen das auf fruchtbaren Boden fällt und ein Umfeld zum Lernen vorhanden ist oder geschaffen werden kann. Wie schon weiter oben erwähnt, oft ist der Aufwand je nach Startpunkt eben höher, zu einem gewissen Punkt zu kommen. Möglich ist es meiner Einschätzung nach sowohl für Studierte als auch für Ausgebildete. In der Praxis startet der Ausgebildete, wenn er keine privat oder anderweitig erworbene Expertise hat, etwas weiter "unten" bzgl. des relevanten Fachwissens. Es gibt, und das ist meine positive Erfahrung damit, Firmen, die handhaben das so. Leider sind die in der Tat noch in der Minderheit. Gruß, Goulasz P.S.: @Errraddicator: In Hessen ist das Duale Studium so formuliert, dass du in einem Betrieb eine Ausbildung absolvierst und nebenbei studierst. D.h. am Ende hast du den Fachinformatiker(Externenprüfung) und den Bachelor. Da man damit einen "niedrigen" und einen "höheren" Abschluss erwirbt halte ich das nur für mäßig sinnvoll, die praxisrelevanten Anteile kann man auch ohne den Ausbildungsrahmenplan erwerben. Eine Stütze für völlig unbedarfte Betriebe ist er aber allemal.

Mahlzeit in die Runde! Das kommt meiner Einschätzung nach ganz darauf an, was man machen möchte. Es war nie so einfach wie heute, an Wissen zu kommen und sich dieses privat anzueignen. Ein Unternehmen zu gründen, an Open Source Projekten mitzuarbeiten, etc. In Konzernen oder für Stellen im deutschsprachigen Raum, bei denen ein Universitätsabschluss Voraussetzung ist, ist ohne diesen natürlich nichts zu holen. Ich bekomme aber über verschiedene Netzwerke auch persönlich von Geschäftsführern und Leuten aus dem Mittleren bis Gehobenen Management regelmäßig mit, dass grade durch die steigende Anzahl von Absolventen das Filtern rein nach Abschluss nicht mehr als Garant für etwas genommen wird. Es wird verstärkt darauf geachtet, ob die entsprechenden Kandidaten durch Referenzen und Projekte Motivation mitbringen, um sich an der entsprechenden Stelle einzusetzen. Ob das Wissen passt, wird dann in einem Probearbeiten bzw. in der Probezeit abgeklopft. Natürlich ist das aufwändiger als einfach die 5 besten Prozent aller Bewerber abzuschöpfen. Aber wer bestimmte Typen von Persönlichkeit für einen Job möchte, für den lohnt sich der Aufwand in der Regel. In der Regel sind das aber auch keine wie schon vorher beschriebenen "Codieräffchen"-Jobs. Wissen kann jeder erwerben, je nach Vorkenntnissen (die man im Studium vermutlich breiter respektive tiefer erfährt) ist der Aufwand dafür eben ohne Studium höher. Eine Haltung und das, was man landläufig als "Leidenschaft" bezeichnet zu erwerben, das lernt man in keinem Studium, und mehr und mehr Arbeitgeber werden sich dessen bewusst. Gruß, Goulasz

Servus! Ich klammere die gängigen IDEs und Tools hier einfach mal aus, die erachte ich nicht als "nützlich" im erwähnenswerten Sinne an, sondern als "unabdingbar zum Arbeiten". Bleibt folgende Liste: Ditto. Ditto ist ein Zwischenablage-Management-Tool, das es erlaubt, mehrere Einträge in der Zwischenablage zu verwalten. Da ich in Code-Reviews oft mit verschiedenen Versionen von Dateien zu tun habe, aus denen ich einzelne Teile kopiere und an anderen Stellen beim Refactoren wieder einfüge, erlaubt mir Ditto, keine manuelle Pufferdatei erstellen zu müssen, sondern einfach mit Strg+C Elemente in die Zwischenablage zu packen und mit Strg+Windows+V (mein persönlicher Shortcut) ein Element aus der Liste zu wählen und dann zu pasten. Meld. Meld ist ein graphisches Diff- und Merge-Tool, das ich zum Vergleichen von Dateien und Beheben von Merge-Konflikten nutze. Bitbucket bietet zwar eine recht gute Diff-Funktionalität, ein besseres externes Diff-/Merge-Tool als Meld ist mir aber bisher noch nicht untergekommen. KeePass2. KeePass ist ein Passwort-Management-Tool mit weitreichender Funktionalität. Ich nutze 2 Tresore, einen für meine privaten Logins und einen für meine beruflichen Zugänge. Momentan sind das Testzugänge in Kundenportale für Tests von SSO-Systemen, Logins für Lizenzen, etc. Es gibt die Option, Tresore im DFS abzulegen und gemeinsam im Team zu nutzen. Grade für Kundenteams, die sich die Zugänge teilen ist das eine gute Lösung, da so nicht jeder immer jeden Zugang manuell aktualisieren muss. Selenium und Selenium IDE. Selenium ist ein extrem mächtiges Tool bzw. Framework zum automatisierten Testen von Oberflächen in Webanwendungen. Mit Selenium IDE als Firefox-Plugin ist es möglich, Click-Sequenzen im Browser aufzunehmen, abzuspielen und zur Weiterverarbeitung in verschiedenen Programmiersprachen und Test-Frameworks (z.B. NUnit und C#) zu exportieren. Fiddler. Ich brauche Fiddler öfter mal, um Aufrufe zwischen verschiedenen Komponenten in Webanwendungen zu tracken und zu analysieren. Bisher habe ich da noch nichts vergleichbares in der Qualität gefunden. Wireframe. Für Skizzen von Benutzungsschnittstellen habe ich bisher noch nichts besseres gefunden. draw.io kann man nutzen, aber Wireframe finde ich speziell für GUIs einfach schlanker, obwohl ich hier in JIRA auch Balsamiq Mockup zur Verfügung hätte. RStudio. Was kann man zu R und RStudio groß sagen? Ich habe selten Programmiersprachen bzw. IDEs erlebt, mit denen man so performant Daten manipulieren und bereinigen kann wie mit R. Ganz davon abgesehen, dass es über den CRAN für Pakete Zugang zu so ziemlich jedem erdenklichen Plug-In gibt. Jeder, der sich öfter mal damit beschäftigt, in Flat Files systematisch Dinge anzupassen, zu löschen oder zu ersetzen und Skripsprachen nicht abgeneigt ist, sei R nahegelegt. TotalCommander. Wurde schon alles zu gesagt. Es best. Es numero uno. Huehuehue. Gruß, Goulasz

Hallo @Caskett! Wenn du das wiederholt automatisiert machst, würde ich dir SQL Server Integration Services ans Herz legen. Da kannst du dann den Output aus einem Execute SQL Task in einer Variable vom Typ Object zwischenspeichern, dir das in den nächsten Script Task übergeben und dort dann ganz normal z.B. per StreamWriter oder auf andere Wege das Result ablegen. Den Task hängst du als Agent Job auf dem Server ein und dann läuft das regelmäßig automatisch im vorgegebenen Intervall. Gruß, Goulasz

Hallo @Crash2001! Du vermischst hier meiner Einschätzung nach Inhalte und Sachverhalte. Es geht bei der Unterscheidung um kausale Durchgriffe in Systemen. Ein Fehler in einem hochkomplizierten Softwaresystem wird sich reproduzieren lassen, solange die Umgebung zum Zeitpunkt der Reproduktion die gleiche ist wie beim ursprünglichen Vorfall. Bei einem Fußballspieler geht das nicht mit Sicherheit. Die Wahrscheinlichkeit, bei gleichen Umständen gleiche Ergebnisse zu erhalten ist hoch, aber nicht 100%-ig. Der wird sich in einer Situation vielleicht genau so entscheiden wie beim letzten Spiel, vielleicht aber auch nicht. Ganz einfach, weil schon Zeit vergangen ist seit dem letzten mal und mindestens der Faktor der menschlichen Psyche (noch) nicht zu 100% einberechenbar ist. Das ist dann aber nicht komplex, sondern kompliziert. Das Verhalten ist bei vollständiger Kenntnis der Systeme vorhersehbar, bzw. kausal rückverfolgbar. Das meinte ich mit: Das Einbringen weiterer Faktoren in so ein System erhöht nur den Grad der Kompliziertheit, führt aber nicht zu "Komplexität". Denk nochmal zurück an mein Beispiel mit dem Uhrmacher. Oder an die Challenger-Katastrophe. Alles hochkomplizierte Systeme, die oft für Experten noch herausfordernd sind. Aber die "Überraschungen" sind keine wirklichen Überraschungen, sondern aufgrund fehlenden Wissens oder versehentlicher Nicht-Beachtung geschehene Fehler, die sich am Ende auf eine oder mehrere klar definierte Fehlerquellen zurückführen ließen. Es geht mir auch nicht um das "Fußball Spielen" an sich. Klar kann ein Roboter Fußball spielen, wenn du ihm die notwendigen Bewegungsabläufe beibringst. Und wenn du ihn mit Sensoren vollpackst, wird er vielleicht auch einen ordentlichen Spielüberblick haben und "Fußball spielen" können. Das, was man allgemein als "Chemie" oder "Intuition" in einer Mannschaft bezeichnet, wird ihm aber fehlen. Bei einem von Menschen bestrittenen Fußballspiel spielen aber so viele Faktoren ins Spiel mit ein, die eben nicht kausal herleitbar oder rückverfolgbar sind. Wenn dem so wäre, müsste ja jedes Spiel Mannschaft A gegen Mannschaft B bei gleicher Aufstellung und gleichem Zustand der Spieler gleich ausgehen. Gruß, Goulasz P.S.: @Mods: Ich habe das Gefühl, wir kapern das Thema hier ein wenig. Wenn es Sinn ergibt, lagert die entsprechenden Postings einfach aus.