Goulasz

So komisch ist die Frage gar nicht. Die Kampagne hab ich durchgespielt, ohne irgendwelche Glitches oder Probleme zu bemerken. Im SnapMap-Editor gibt es wohl noch einige Probleme bei großen Karten, aber da ist man wohl dran. Multiplayer-Balancing passiert ja idR eh durch Patching im Nachgang.

Bild hat Bezug.

Ich denke der Bedarf rührt auch daher, dass Anforderungen an Software mittlerweile einfach dynamischer und flexibler sind als das vor ein paar Jahren noch der Fall war. Grade im IT-Bereich geht der Fokus weg von riesigen Applikationen hin zu kleineren, schlanken, leicht zu bedienenden Tools("Apps"), die ganz spezifische Probleme lösen und nicht den Anspruch haben, die eierlegende Wollmilchsau zu sein. Dafür aber schnell verfügbar und einsatzfähig. Zumindest ist das meiner Einschätzung nach außerhalb der ganz großen Konzern-Enterprise-Welt immer mehr so. Auch Menschen, die ich jetzt eher nicht als "Digital Natives" bezeichnen würde, kriegen über Ecken und Endprodukte für den Consumermarkt(iPhone etc.) mit, was an leichtgewichtigen Lösungen mittlerweile möglich ist. Wenn es aber stärker Richtung "Leicht bedienbare Software zur Lösung konkreter Probleme" geht und der Fokus weniger auf "SAP-Klon, der von Haus aus einfach ALLES kann aber garstig zu bedienen ist" liegt, kommt man mit den altgedienten tayloristischen Management-Methoden und Wasserfall-Planung nicht mehr so weit. Meine Beobachtung hier ist, dass sich diese Erkenntnis langsam aber sicher verbreitet, und vor allem dass agile Methoden keine hippen Buzzwords sind, mit denen man Mitarbeiter zieht, sondern, dass sie für manche Anforderungen spürbaren Mehrwert(time to market) bringen. Ein iteratives Vorgehen und ein Herantasten an die bestmögliche und effizienteste Lösung(über MVPs) werden wichtiger. Und das bringt implizit Anforderungen an Software und Architektur mit sich. Wenn ich schnell Feedback brauche, kann ich es mir nicht leisten, jedes Feature komplett manuell durchzuklicken und durch die QA/Test-Abteilung zu jagen. Es kommt der Punkt, wo Entwickler gefühlt schneller Features entwickeln, als getestet werden kann. Also wird das automatisiert. Zack, hat man ne CI-Pipeline. Damit es mit dem Hosting klappt, hat man auf einmal nen Admin im Team. Und weil man ja auch irgendwie nahe beim Kunden sein will und das ganze auch irgendwie abrechnen möchte, landet man logischerweise in so einem Vorgehen oft bei einem crossfunktionalen Team, das die gesamte Wertschöpfungskette abbilden kann. Gruß, Goulasz

Mahlzeit! Wer von euch hat es(noch), plant es sich anzuschaffen und wie ist euer Eindruck bisher? Ich war ja schon spätestens nach dem E³ Gameplay-Trailer heiß wie frittenfett. Und zumindest für den SinglePlayer-Modus wurde meine persönliche Erwartungshaltung übertroffen. Das Originalspiel hab ich '99(im zarten Alter von 13 Jahren, kurz nachdem ich Cannibal Corpse für mich entdeckt habe) gespielt, als es auch schon das grafisch deutlich bessere Half-Life auf dem Markt gab. Nichtsdestotrotz übte Doom damals™ auf mich eine ziemliche Faszination aus. Nach Freitag hat sich daran nichts geändert. Mittlerweile hab ich so etwa 11 Stunden Playtime in der Kampagne und ich bin immer noch total angefixt. Das Gameplay ist unfassbar schnell, meine anfänglichen Bedenken, die "Glory Kills" würden die Geschwindigkeit eher drosseln als sie "oben zu halten" wurden völlig ausgeräumt und die Waffen machen richtig Spaß. Die verschiedenen Gegnertypen und ihre Stärken und Schwächen passen super, ich hab es auf "Hurt me plenty"(normal) schon mehrfach geschafft, zu sterben, weil ich unaufmerksam war oder die falschen Gegner zuerst in den Fokus genommen habe. Auch die SnapMap-Funktionalität ist großartig. Ich denke für Szenarios und Co-Op-Action wird da noch einiges kommen. Den Multiplayer habe ich bisher noch nicht angespielt, da war ich in Shootern(abseits von Quake 3 Arena) aber noch nie so der Bringer. Und ihr? Gruß, Goulasz

Moin! Hier dazu ein alter(16 Jahre) aber immer noch brandaktueller Artikel aus Joel Spolskys(StackExchange, Trello, ehemals Microsoft) Blog: The Joel Test: 12 Steps to Better Code Zum konkreten Inhalt: Ich finde die Fragen, die du stellst, ziemlich gut. Allerdings daraus ein "1-5 Punkte"-System abzuleiten war eine nicht so gelungene Aktion. Da bin ich bei meinen Vorrednern. Wir sind aber zwischen 4 und 5, mit starker Tendenz zur 5. Amüsanterweise sind unsere "Patterns & Practices" und unser Tooling im Bereich Softwareentwicklung bedeutend besser als im Bereich Data Warehousing und Data Science, obwohl unsere Kernkompetenz eigentlich die Datenverarbeitung ist. Aber das ist ein Posten, an dem grade akut gearbeitet wird. Gruß, Goulasz

Hallo @arlegermi! Danke erstmal für den Kommentar! Die Kommunikation läuft so, wie sich das Team entscheidet. Der Vorteil daran ist ja das implizit vorhandene Protokoll von Kommunikation. Wer möchte, bekommt Push Notifications, wer das nicht möchte, guckt nur einmal am Tag rein. In den meisten Teams gibt es im- oder explizite Standards, auf die sich bzgl der Kommunikation committed wird. Slack ersetzt keine Kommunikationsstrukturen, es ist ein weiterer, bequem zu nutzender Kanal. Dringende Dinge wirst du immer noch am besten face to face oder am Telefon erledigen. Daran ist auch nichts wirklich revolutionär. Der Mehrwert kommt davon, wie man das Tool nutzt. Nicht davon, dass man es nutzt. Solche Allheilmittel gibt es nicht. Wer mit seinen vorhandenen Tools gut fährt, bitte bloß nichts daran ändern, weil Slack grade irgendwie "hip" ist. Für die, die da noch gar nichts haben oder unzufrieden sind, ist es mMn nur echt interessant. Gruß, Goulasz

Das kannst du nicht nur, das solltest du sogar. Hier wird dir niemand eine verbindliche Antwort geben können. Nur Ratschläge basierend auf Vermutungen und Erfahrung. Im Gegensatz zu deiner IHK, die wissen in der Regel, was sie wollen. Gruß, Goulasz

Hallo Welt! Technische Blogbeiträge die Zweite. Heute möchte ich euch ein Tool vorstellen, dessen Einsatzfelder im Beruf unfassbar flexibel sind. Wie der Titel schon vermuten lässt, handelt es sich um Slack. Slack - be less busy Wir nutzen das zwar leider (noch) nicht in der Firma, aber privat haben wir schon den ein oder anderen Slack-Channel aufgesetzt, um uns mit dem Funktionsumfang vertraut zu machen. Und der ist schon in der kostenfreien Variante wirklich ansehnlich. Also, heute kurz und knackig: Was ist Slack und was kann das? Der ein oder andere kennt sicherlich noch den guten alten IRC. Auf den ersten Blick ist Slack auch erstmal nicht viel mehr als das. Ein Online-Messenger, der im Browser oder per App(iOS, Android, Windows Phone(noch Beta)) genutzt werden kann. Eigene Kanäle, zu denen man Mitglieder hinzufügen und löschen kann. Zu den Slacks, die die verschiedenen Kanäle enthalten, wird man vom Administrator des Slacks eingeladen. Slack bietet "Räume" für verschiedene Subthemen innerhalb eines "Slacks" an So weit, so bekannt. Von der App abgesehen erstmal nichts wirklich bahnbrechendes. Abgesehen davon, dass Slack einen ungeahnt guten Parser besitzt, der z.B. Tweets direkt im Kanal per Vorschau anzeigt und auch Links zu Bildern automatisch einbettet. Aber wie gesagt, das ist nur der erste Blick. Slack hat unter der Haube einige Funktionen parat, die aus diesem schlank daherkommenden Messenger ein mächtiges Collaboration-Tool für den Betrieb machen (können). Ok, und wo ist jetzt der Mehrwert für mich? Ganz einfach: Slack ist, was du draus machst. Slack bietet von Haus aus Benachrichtigungen für und von diversen andere Tools an. Selbst für die Tools, die noch keine native Unterstützung haben, gibt es in den meisten Fällen gitHub-Projekte oder Zaps, die diese Funktionalität anbieten. Beispiele gefällig? #1: Bernd erstellt in Bitbucket einen Feature-Branch für seine neue App. Commits und Pushes nach remote werden automatisch in entsprechenden Branches angezeigt und können dort durchsucht und kommentiert werden. Man muss sich als Entwickler nicht durch endlose Commits wühlen, sondern kann einfach direkt einsehen und suchen, was wann passiert ist. Und wenn man möchte, guckt man einfach in den Commit-Details nach. Kleiner Wermutstropfen: Slack gibt es bisher nicht on Premise. Wer also etwas Vergleichbares intern aufsetzen will, muss wohl auf HipChat oder ähnliches ausweichen. Automatische Channelupdates per Trello-Integration #2: Ein agiles Team hat sich ein SmartBoard angeschafft und nutzt ein Trello-Board zur Verwaltung ihrer Tasks. Leider sitzen nicht alle Teammitglieder in einem Raum. Durch die Trello-Integration mit Slack werden Aktivitäten der Tasks auf dem Board automatisch in einen Slack-Channel mit übertragen. Teammitglieder können sich so auch außerhalb der Daily Stand-Ups einen Überblick über die Tätigkeiten verschaffen. Guckt einfach mal rein. Für die meisten Dienste und Apps, die ich kenne, gibt es bereits eine Unterstützung in irgend einer Form in Slack. Was kostet das? Gar nichts. Also in der Basisversion. Und die reicht zum Evaluieren oder für kleine bis mittelgroße Teams definitiv aus. Für alles darüber gibt es in der Preisübersicht einen guten Überblick über die Kosten. Besonders schön: Die "Einarbeitung" in das Tool benötigt nicht mal sonderlich viel Zeit. Jeder, der schon mal irgendwie in einer WhatsApp-Gruppe war, wird sich mit den Grundfunktionalitäten von Slack in Browser und App schnell vertraut machen. Alte IRC-Nerds sogar noch besser. Fazit – TL;DR Slack ist ein leichtgewichtiges, aber mächtiges Tool, das es dem Benutzer ermöglicht, sich mit anderen Nutzern auszutauschen. Dokumente, Statusupdates, Informationen, alles voll durchsuchbar und indiziert. Wer sich davon nicht abschrecken lässt, dass es "in der Cloud" läuft, sollte Slack definitiv mal ausprobieren. Der potentielle Mehrwert, grade für räumlich getrennte Teams ist nicht zu unterschätzen. Euer "devopsdad" Patrick

Hallo @Michl92! Ein Proof of Concept als Projekt ist völlig in Ordnung. Mein Projekt ging auch nicht unmittelbar in Produktion. Ich habe eine nicht-monetäre Bewertungsmöglichkeit(konkret: Nutzwertanalyse) zur Rechtfertigung des Entwicklungsaufwandes benutzt. Ist in deinem Antrag zu erkennen, dass es sich um so einen "Proof" handelt oder hast du dort von einem für einen internen oder externen Kunden zu entwickelnden Produkt gesprochen? An sich ist die Dokumentation in allen Phasen das Mittel der Wahl, um diesen Sachverhalt darzustellen. Auch ein gescheitertes Projekt kann eine sehr gute Note ergeben, wenn klar ist, warum das Projekt nicht erfolgreich durchgeführt werden konnte und dies gut dokumentiert ist. Im Übrigen scheitern auch im "echten Leben" sehr, sehr viele Projekte. (Meist aufgrund schlechter Abstimmung der tatsächlichen Anforderungen) Eine Betrachtung der Wirtschaftlichkeit innerhalb der Doku ist eigentlich immer notwendig. "In echt" lässt dich auch niemand aus Jux und Dallerei irgendetwas entwickeln, wenn er sich davon nichts erhofft. Bei deiner zuständigen IHK sollte es dort Infomaterial geben. Hier ist der Link zu meiner Kammer: Berufsinformation und Dokumente Fachinformatiker IHK Kassel/Marburg Gruß, Goulasz