TextMate ist gut und schön, aber man sollte nicht auf den guten alten BBEdit vergessen, den es seit dem guten alten MacSystem6 gibt nun für das aktuelle MacOS  in Version 12.

Echt toller Beitrag! Vielen Dank dafür. Wir haben uns ebenfalls ein wenig mit Kubernetes beschäftigt und einen Beitrag dazu veröffentlicht. Wer mehr über die genaue Funktionsweise von k8s und seinen Einsatz im Bereich der Cloud Anwendungen erfahren möchte, kann gerne mal reinschauen:  --> https://www.incloud.de/themen/kubernetes Liebe Grüße Franz

Dokumentation ist ja meist "grüne Wiese" wir haben gute Erfahrungen mit dem Tool Fast-Help gemacht. Damit kann man auch eine F1 Hilfe erzeugen. z.B. CHM oder PDF

Vielleicht interessant in dem Kontext: ich habe auf der SE-Live mal einen Vortrag zu "Agiler Dokumentation" gehalten: https://www.youtube.com/watch?v=MkYHspL2K8g

GitHub ist so fehlerfrei gestaltet, dass es den Entwicklern Pull-Anfragen liefert, damit sie vor dem Senden des Endprodukts kommunizieren können. Ich würde es allen empfehlen.[Anm. d. Red.: Link bezog sich nicht auf das Thema.]

Ach, iwo lustig, im Vorspann stimmt es. Aber danke für den Hinweis, werde ich morgen sofort ändern. Stephan Augsten

Sehr geehrter Herr Jacke, hier erst einmal der Link zum zweiten Teil: https://www.dev-insider.de/dokumentationsarten-in-der-uebersicht-a-788072/ ... mit dem Versprechen, die Beiträge noch besser untereinander zu verlinken. In gedruckter Form gibt es unsere Artikel nicht, einige werden allerdings im monatlichen CIO-Briefing aufbereitet. Zudem bieten wir auch eBooks an, demnächst beispielsweise zum Thema Low-Code-Entwicklung. in der Vergangenheit zu Agile, DevOps und Blockchain. Herzlichen Dank für Ihre Anfrage und beste Grüße Stephan Augsten

Danke für das gute Tutorial. Ich würde mich sehr freuen, wenn es vielleicht noch weiter ausgebaut wird. Ist auf jeden Fall verständlich als viele andere Sachen im Netz. Vorallem für komplett Neulinge wie mich.

Künftig wird jedem Akademiker technisches Wissen abverlangt- ob Rechtsanwalt oder Geologe. Selbst die Programmierung sollte künftig nicht mehr als „Spezialisierung“ angesehen werden, sondern als fachübergreifendes Grundwissen! Dennoch gibt es natürlich viele Themen wie künstliche Intelligenz, auf die man sich spezialisieren kann und somit weiterhin als „Experte“ gilt. Das Verständnis ist notwendig, um dem Mangel an passenden Arbeitnehmern nachhaltig entgegenzuwirken. Umschulungen sind sicher wichtige Maßnahmen, zumal digitalisierte Prozesse den Bedarf an klassischen Arbeitsprofilen weiterhin reduzieren werden. Der langfristig beste und für die Menschen einfachste Weg ist es jedoch, bereits in der (Grund-)Schule den verantwortungsbewussten Umgang mit IT Systemen spielerisch zu erlernen. Auf der Basis kann man zum Beispiel auch im Jahr 2025 ein Bankfachwirt werden, jedoch in dieser Position die Self Services der Kunden monitoren bzw. gezielt die Workflows anpassen. Der Bankschalter ist zur Rezeption degradiert und die Bankfiliale wird zu einem Flagship-Store der Bank, da das Geld in absehbarer Zeit ein digitales Zahlungsmittel sein wird - nur ein Beispiel. Vereinfacht kann man es auch so verstehen, dass es klassische Berufe weiterhin geben wird, jedoch der Inhalt durch IT geprägt sein wird und sich die Anforderungen entsprechend ändern. Dabei ist positiv zu vermerken, dass die sinnbestätigenden Aufgaben durch die Digitalisierung nicht weniger werden- im Gegenteil!

Hallo Frau Divkovic, sehen Sie die Notwendigkeit einer agilen Unternehmenskultur als Basis "für die Implementierung" von DevOps? Gruß, Andreas Zajdziuk  

Hallo Lewin, ich folge Deinem zweiten Absatz, das vor allem größere Unternehmen weiterhin econonic of scale Ansätze verfolgen sollten. Hierbei legt vielleicht ein Qualitätsaudit a la Google einen Maßstab nach der die Applikationsverantwortung an ein Querschnittsteam "Ops", einem Site Reliabiltiy Engineer-Team übergeben wird. Die freiwerdenden Kreativkapazitäten können so neue Werte schaffen, während der Regelbetrieb unauffälliger, "bugfree" Software bequem durch einen zentralen Betrieb alter Tradition verantwortet wird. Bei Deinem ersten Absatz irritiert mich zum Einen  die von Dir verwendete Form von DevOps: DevOps ist meiner Meinung nach eine Kultur; keine Einzelperson und auch keine Teilmenge eines IT-Bereichs. Genauso wie ich es äußerst verwirrend finde das eine Stelle als "DevOps Engineer" ausgeschrieben wird, oder das es "DevOps-Tools" geben soll. Es gibt Tools für Repositories, zum Testing, zur Gestaltung eines Workflows ... sie arbeiten allesamt ganz autark, ohne Anwesenheit einer DevOps-Kultur https://jaxenter.de/agile-devops-innersource-interview-77536 Bzgl. Support sehe ich, zumindest in großen Organisationen, unterschiedliche Verantwortlichkeiten: CPU, Storage, Netzwerk, Virtualisierung, Daten & Traffic, etc. und Monitoring, Orchestrierung, Applikationen. Für den (Rest-)Anteil "Applikation" sehe ich  die 100%ige Support-Verantwortung (also inkl. 7x24) beim Entwickler. Dies sorgt ganz schnell und kostengünstigst für "bugfree" Software, abgesehen von den Lerneffekten  

Ich habe neulich den blinden Barrierefreiheits-Dozenten Domingos de Oliveira gesehen und war beeindruckt, wie schnell diese Vorleseprogramme arbeiten. Ganz interessante Informationen dazu gibt es auf seiner Website www.netz-barrierefrei.de

Danke für Überblick. Taiga bietet sowohl Kanban als auch Scrum Untersützung und scheint Weekan sehr ähnlich zu sein. Dort lässt sich außerdem ein WIP definieren oder der Backlog Burndown beobachten. Taigas Backend basiert auf Python/Django, für die UI kommt Angular zum Einsatz.

Eberhard Wolff, Experte für Microservices, erläutert hier auch nochmal kurz und prägnant diesen aktuellen Architektur-Trend und zeigt Vorteile und Herausforderungen auf: https://www.microtool.de/wissen/microservices-der-aktuelle-architektur-ansatz/

Ich sehe das auch so, dass eigentlich alle zu mindest mir bekannten Sprachen Strukturierte Programmierung zulassen. Allerdings beinhalten auch so ziemlich alle Sprachen unstrukturierte Möglichkeiten, die strenggenommen versteckte GOTOs darstellen. Beispiel wären hier: continue in Schleifen break in Schleifen Returns inmitten von Prozeduren (Funktionen) Es gibt verfechter der Strukturierten Programmierer (wie ich), die Code nur dann für strukturiert empfinden, wenn es sich in ein Struktogramm eins zu eins überführen lässt. Andererseits gibt es auch Stimmen, die gar nichts davon halten.