Whiz-zarD

Als geht es dir nur ums Ansehen? Ich hab auch einige Projekte auf GitHub und sie wurden noch nie runtergeladen. Na und? Ich mache diese Projekte für mich, weil ich sie gerade brauche und stelle sie halt zur Verfügung. Wo ist nun dein Problem? Und ganz ehrlich: Ein Ticketsystem? Wozu? Es gibt Tonnenweise Open Source-Systeme oder für kleine Gruppen kostenlose Cloud-Lösungen, wieso sollte ich ausgerechnet ein kostenpflichtiges System nehmen, das von einer Person entwickelt wird und der es von Heute auf Morgen einstellen könnte?

was gesucht wird: zufallszahlGroesserZehn wie die Methode heißt: ZufallszahlGroesserZehn Finde den Fehler.
Hinweis: Groß- und Kleinschreibung spielt eine Rolle.

Du sagst, die Zahl soll größer 10 sein. Schaue dir noch mal deine Methode an.
Und auch wenn es im Browser läuft. Es hindert ja keinen, den Code zu kopieren und in einer Entwicklungsumgebung einzufügen.

was gesucht wird: zufallszahlGroesserZehn wie die Methode heißt: ZufallszahlGroesserZehn Finde den Fehler.
Hinweis: Groß- und Kleinschreibung spielt eine Rolle.

Du sagst, die Zahl soll größer 10 sein. Schaue dir noch mal deine Methode an.
Und auch wenn es im Browser läuft. Es hindert ja keinen, den Code zu kopieren und in einer Entwicklungsumgebung einzufügen.

was gesucht wird: zufallszahlGroesserZehn wie die Methode heißt: ZufallszahlGroesserZehn Finde den Fehler.
Hinweis: Groß- und Kleinschreibung spielt eine Rolle.

Aber noch mal Back to Topic:
Es gibt auch Zertfikate für Softwaretester. z.B. Zertifikate durch ISTQB (International Software Testing Qualifications Board). Vielleicht ist ja sowas für dich.

Ich melde mich mal aus der QS-Abteilung:
Generell sollte man erst einmal zwischen Entwicklertests und Tests von dedizierten Testern unterscheiden.
Entwicklertests sollten immer in Form von Unit-Tests bei der Entwicklung durchgeführt werden. Unit Tests werden normalerweise nicht von Softwaretestern durchgeführt, sondern ist Aufgabe von der Entwicklung!
Wir setzen als Testabteilung aber gar nicht mehr auf Code-Ebene an und testen nur noch nach dem Blackbox Verfahren auf Systemebene. Das bedeutet es werden Testfälle erstellt, die auf nur über das Frontend Oberfläche der Software durchgeführt werden. Schnittstellen werden mithilfe von SOAP-UI getestet, automatisierte Tests werden mithilfe von Ranorex erstellt.
Automatisierte Tests sind wichtig und kostensparend, sobald man mehrere Testiterationen hat. Beispiel:
Es soll eine neue Software eingeführt werden. Es ist abzusehen, dass es mehrere Releases pro Jahr geben soll. Wenn man dann durchrechnet, dass 4x ein manueller Regressionstest pro Jahr mit einem Aufwand von je 50 Personentagen durchgeführt werden soll, kommt man auf eine deutlich höhere Summe als wenn man automatisiert die Regressionstests durchlaufen lässt. Der Initialaufwand für den Aufbau ist natürlich höher, danach hat man aber zuverlässige, leich wartbare Regressionstests.
Unsere Testabteilung führt (fast) nur Blackbox Tests durch und wir sind eine Abteilung von knapp 80 Leuten.
Da kann ich leider nicht zustimmen. Wir haben tatsächlich reine Testautomatisierer. Dafür gibt es verschiedenste Schulungen und die Thematik ist ziemlich komplex. Gerade wenn es um eine Automatisierung mithilfe von sehr mächtigen Testtools wie Selenium und Ranorex durchführt. Testautomatisierer werden bei uns auch teilweise besser bezahlt als Testmanager.
Oh doch, wer kennt keinen Critical Bug nach Release auf die Produktionsumgebung. Hier eine schöne Grafik (wie man sie zu Massen findet) dazu:

Zu oft führen genau solche kritischen Fehlern zu Schlagzeilen in der Presse, die durch einen guten und vollständigen Test gefunden hätten werden können.
@nadine2501: Ja, es werden explizit Software Test Engineers, Quality Assurance Engineers, Software Tester o.Ä. gesucht. Der ISTQB bietet, wie von @Whiz-zarD schon richtig erwähnt, zahlreiche Schulungen und Fortbildungen zum Thema Test an. Angefangen vom Foundation Level mit der Certified Tester über den Advanced Level wie den Technical Test Analyst bis hin zum Expert Level Testmanager. Der Markt hier sieht ziemlich gut aus, da das Testing immer wichtiger in der IT-Unternehmenskultur wird und das entsprechende Know-How aufgebaut und gesucht werden muss. Wenn Du Dich privat bei mir meldest, kann ich Dich auch eventuell weitervermitteln

Ggf. wäre das Ganze Thema Testing auch einen eigenen Thread wert. Muss gestehen die Beispiele und Folgen, die @Whiz-zarD erwähnt hat sind so ziemlich die genauste Beschreibung meines Alltags, die ich bis dato gelesen habe.
Testen generiert natürlich kein Geld, spart es aber auf der anderen Seite. Meist rächt sich das eben, da sowohl das Finden von Bugs, als auch die Dauer von Erweiterungen und das neue Hinzufügen von Bugs kosten verursacht, die den Kunden oft auch nicht in Rechnung gestellt werden.
Am Ende kommt es dann raus ala die Entwicklung von Feature X ist durch nicht Schreiben von Tests 3 Stunden schneller, dafür gibt es hinten rum 10 Stunden Fehlerbehebung auf Gewährleistung und alle Erweiterungen darum dauern mal eben ein paar Stunden länger. Klar ist das schwer hier und jetzt zu beziffern. Ist eben dieses Instant Gratification Monkey verhalten. Es geht um Geld das jetzt verdient wird und für den Kunden um Geld das jetzt gespart wird, später ist später..
So endet man eben gerne da, wo es @Whiz-zarD beschrieben hat. Manuelles Testen ist ewig aufwendig, keiner mag mehr die heiklen Stellen anpassen. Es gibt Triggert, Events und Jobs, die oben drauf kommen, die Performance runterreißen, Fehler werden nicht an den Stellen behoben, wo sie entstehen, sondern es gibt Jobs, die kaputte Daten korrigieren usw.
Am Ende hat man einen gefühlt unwartbaren Haufen Code, wo nur noch ganz wenige wirklich durchsteigen. Man schwerer Leute findet die damit arbeiten können, Arbeitsbelastung für einige wenige förmlich explodiert etc.pp. Hängt imo ein riesen Rattenschwanz dran. Aber immerhin hat man vorher ein paar Stunden gespart.
Das Unternehmen will die Tests natürlich nicht zahlen, dann landen sie ggf. als einzelner Punkt im Angebot. Der Kunde setzt da den Rotstift an und möchte gerne manuell selber testen, tut er natürlich nicht und am Ende knallt es.
Tests im Sinne von es gibt keine Fehler und es kommen keine Fehler rein gibt es nicht aber zumindest weiß man, dass die definierten Fälle funktionieren. Man entkoppelt gezwungenermaßen ein wenig, was Erweiterung vereinfacht und man traut sich an den Code, was auch wieder die Qualität besser hält.
Ich kann leider dem System geschuldet i.d.R. nur Integrationstest und Simulatoren für die Gegenseite schreiben aber alleine das hat mir so unendlich viel Arbeit gespart und viele Features erst möglich gemacht, die ich mir so ohne definitiv nicht zugetraut hätte, davon ab dass alleine das manuelle Testen das Budget um ein Vielfaches überschritten hätte und mir Cheffe den Kopf abgerissen hätte.
Ist eben was anderes ob man hunderte Situationen automatisiert innerhalb einer Stunde testen kann oder alleine ein Test aufbauen Stunden dauert und man das mit hundert multiplizieren darf. Und bei komplexen Anwendungen passiert das fix. Stammdaten in die Datenbank, Aufträge in die Datenbank, zig Prozesse hintereinander ausführen, die alle den Datenstand von den vorherigen Prozessen brauchen etc. pp.
Klar skippen viele so auch das manuelle Testen, da es nicht ins Budget passt. Dann macht man kleine Änderungen mal einfach so... wird schon nix passieren etc. pp.
Edit. Bzgl. Thread kapern, da es eben Bezug hat auf Antworten davor, die das gleiche Problem haben. Müsste man generell im Idealfall eh mal kurz mit der Schere ran. Mal als Edit, da nicht noch mehr nach unten spammen möchte

Aber noch mal Back to Topic:
Es gibt auch Zertfikate für Softwaretester. z.B. Zertifikate durch ISTQB (International Software Testing Qualifications Board). Vielleicht ist ja sowas für dich.

Dafür wird die Zeit dann mit manuellen Tests verplempert und sorgt für Fehler und regt jeden nur auf. Willkommen in der Test-Hölle, wo die Test-Pyramide auf dem Kopf steht.
Automatisierte Tests werden immer wichtiger, um konkurrenzfähig zu bleiben, da Software immer komplexer wird und manuelle Tests schlecht skalierbar sind. Zu mal in einer agilen Softwareentwicklung automatisierte Tests unabdingbar sind. Kannst ja gerne mal in meiner Firma anfangen, um zu sehen, was passiert, wenn man keine automatisierten Tests entwickelt werden, da die Softwarearchitektur dies nicht bzw. nur mit extrem hohen Hürden zulässt.
Testautomatisierung dient auch dem Kunden, da damit Fehler im Vorfelde gefunden werden und auch Geld einspart, da Fehler sofort gefunden werden und nicht erst, wenn der Kunde schon das Release bekommen hat. Das erhöht auch die Kundenzufriedenheit und sorgt auch für eine Zufriedenheit unter den Entwicklern. Nichts ist schlimmer, als ein Fehler gemeldet zu bekommen, wo man erst mal Tagelang analysieren muss, wo der Fehler herkommt und in der Zwischenzeit die nächsten Fehler gemeldet werden. 
Testautomatisierung hilft auch dem Refactoring, da man eben das Verhalten der Anwendung kennt und die Anwendung nicht zum Einsturz bringt, nur weil man irgendwo an einer Wurzel zieht. Oft ist es so, dass man dreckige Stellen im Code gar nicht mehr anfässt, weil man eben nicht weiß, was passieren wird, wenn man sie anfasst. Mit Testautomatisierung wüsste man es. Folglich wird der Code auch immer schmutziger, weil man um diese Stelle drumherumbaut. Das wiederum hat zur Folge, dass Entwicklungen von neuen Features immer aufwendiger werden und der Schrei nach einer Neuentwicklung von Entwicklern wird immer größer und hinterher steht man dort mit einer über 10 Jahre alten, historisch gewachsenen, dreckigen Software, die so groß ist, sodass eine Neuentwicklung praktisch unmöglich erscheint und die Kunden immer unzufriedener werden und sich was anderes suchen.

Dafür wird die Zeit dann mit manuellen Tests verplempert und sorgt für Fehler und regt jeden nur auf. Willkommen in der Test-Hölle, wo die Test-Pyramide auf dem Kopf steht.
Automatisierte Tests werden immer wichtiger, um konkurrenzfähig zu bleiben, da Software immer komplexer wird und manuelle Tests schlecht skalierbar sind. Zu mal in einer agilen Softwareentwicklung automatisierte Tests unabdingbar sind. Kannst ja gerne mal in meiner Firma anfangen, um zu sehen, was passiert, wenn man keine automatisierten Tests entwickelt werden, da die Softwarearchitektur dies nicht bzw. nur mit extrem hohen Hürden zulässt.
Testautomatisierung dient auch dem Kunden, da damit Fehler im Vorfelde gefunden werden und auch Geld einspart, da Fehler sofort gefunden werden und nicht erst, wenn der Kunde schon das Release bekommen hat. Das erhöht auch die Kundenzufriedenheit und sorgt auch für eine Zufriedenheit unter den Entwicklern. Nichts ist schlimmer, als ein Fehler gemeldet zu bekommen, wo man erst mal Tagelang analysieren muss, wo der Fehler herkommt und in der Zwischenzeit die nächsten Fehler gemeldet werden. 
Testautomatisierung hilft auch dem Refactoring, da man eben das Verhalten der Anwendung kennt und die Anwendung nicht zum Einsturz bringt, nur weil man irgendwo an einer Wurzel zieht. Oft ist es so, dass man dreckige Stellen im Code gar nicht mehr anfässt, weil man eben nicht weiß, was passieren wird, wenn man sie anfasst. Mit Testautomatisierung wüsste man es. Folglich wird der Code auch immer schmutziger, weil man um diese Stelle drumherumbaut. Das wiederum hat zur Folge, dass Entwicklungen von neuen Features immer aufwendiger werden und der Schrei nach einer Neuentwicklung von Entwicklern wird immer größer und hinterher steht man dort mit einer über 10 Jahre alten, historisch gewachsenen, dreckigen Software, die so groß ist, sodass eine Neuentwicklung praktisch unmöglich erscheint und die Kunden immer unzufriedener werden und sich was anderes suchen.

Für mich sieht es sogar so aus, dass die zweite Schleife falsch ist und jetzt deine Lösung richtig ist.
Die zweite Schleife macht ja keinen Sinn. Sie durchläuft ja nun die Spalten der Zeilen aber das ist nicht nötig, da die Spalten über einen Index angesprochen werden.
Du könntest aber die Zeilen:
kopierezeile(liste, fehler, i, aktuellezeilefehlerarray) aktuellezeilefehlerarray++ in:
kopierezeile(liste, fehler, i, aktuellezeilefehlerarray++) ändern. Das hat den selben Effekt, da das Doppel-Plus eine Post-Inkrement-Operation ist. D.h. es wird nach dem Abrufen des Wertes dieser inkrementiert.

Ein offenes BilligNAS mit Zugriff durchs Internet ... kann genauso gefährlich sein wie eine Cloudlösung von OnkelTom ...
Ich würde mich nicht nur auf ein BilligNAS verlassen .... davon liegen bei uns zuviele im Müll
Aber ohne sicheres VPN spielst Du mit dem Feuer

Das Thema hat absolut nichts mit Boxing und Unboxing zu tun, denn Boxing und Unboxing ist was anderes. Boxing und Unboxing wird verwendet, um Wertetypen (integer, double, ...) in Objekte zu wandeln (boxing) und von Objekten wieder zurück in Wertetypen (unboxing). Beispiel für Boxing:
int i = 123; object o = i; // boxing Beispiel für Unboxing:
o = 123; i = (int)o; // unboxing So etwas wird verwendet, wenn man z.B. eine Liste mit unterschiedlichen Datentypen hat:
var list = new List<object>(); In diese Liste kann dann alles reingeschrieben werden. Sei es z.B. Strings oder Integers.
Das Thema, was @redstav anspricht, ist "Vererbung" und Vererbung ist die Haupteigenschaft der Objektorientierung.
Abstrakte Klassen können nicht instanziert werden. Sie können nur vererbt werden, wie in dem Beispiel. Mit abstrakten Klassen können nämlich Grundgerüste geschaffen werden, die dann mit den Subklassen verfeinert werden können. Das Grundgerüst garantiert uns, dass die Subklassen die Eigenschaften und Methoden der abstrakten Klasse besitzt.
Dein Beispiel finde ich aber nicht so toll, da es die abstrakten Klassen schlecht veranschaulicht. Ich versuche es mal mit einem anderen Beispiel: Angenommen wir wollen geometrische Figuren auf dem Bildschirm malen. Wir haben ein Quadrat und ein Kreis und wollen sie als Klassen abbilden. Beide Figuren sollen später mit einer Farbe ausgefüllt werden und sollen eine Methode besitzen, die dafür sorgt, dass die Figur auf dem Bildschirm gemalt wird. Fangen wir naiv an:
public class Square { public double Width { get; } public Color Color { get; } public Square(double width, Color color) { this.Width = width; this.Color = color; } public void Paint() { // Malt Quadrat auf den Bildschirm } } public class Circle { public double Radius { get; } public Color Color {get; set;} public Square(double radius, Color color) { this.Radius = radius; this.Color = color; } public void Paint() { // Malt Kreis auf den Bildschirm } } Nun haben wir zwei tolle Klassen. Nun kommt die Vererbung ins Spiel: Wir sehen, dass der Aufbau beider Klassen dort recht identisch ist. Also können wir eine Grundgerüst - also eine abstrakte Klasse - bauen:
public abstract class Shape { public Color Color {get; set;} public Square(Color color) { this.Color = color; } public abstract void Paint(); } public class Square : Shape { public double Width { get; } public Square(double width, Color color) : base(color) { this.Width = width; } public override void Paint() { // Malt Quadrat auf den Bildschirm } } public class Circle : Shape { public double Radius { get; } public Circle(double radius, Color color) : base(color) { this.Radius = radius; } public override void Paint() { // Malt Kreis auf den Bildschirm } } Square und Circle besitzen nun durch die Vererbung die Eigenschaften von Shape. Mit der abstrakten Paint()-Methode geben wir dann noch zusätzlich an, dass die Methode zwar in den Subklassen zur Verfügung steht aber die konkrete Implementierung in den Klassen Geschehen muss. So wird dann garantiert, dass alle Klassen, die von Shape erben, auch die Paint()-Methode besitzen. Dies ist jetzt nämlich vom Vorteil, denn wir wollen ja geometrische Figuren auf dem Bildschirm zeichnen. Derjenige, der jetzt dafür sorgt, dass die Figur auf dem Bildschirm gezeichnet wird, muss nämlich nicht wissen, ob es nun ein Quadrat oder Kreis ist, sondern muss nur wissen, dass sie vom Typ Shape sind:
public class Screen { public void Paint(Shape shape) { shape.Paint(); } } Screen screen = new Screen(); Square square = new Square(12.5, Color.RED); Cirlce circle = new Circle(10, Color.BLUE); screen.Paint(square); screen.Paint(circle); Die Paint()-Methode in der Screen-Klasse muss also nicht den konkreten  Datentyp (Square oder Circle) wissen (ansonsten müssen wir jeden Typ eine eigene Methode schreiben), sondern muss nur wissen, dass die Klasse vom Typ Shape sein muss, um die Paint-Methode aufrufen zu können.
In den Klassen Square und Circle erkennt man auch, dass beide zwar vom Typ Shape sind aber beide haben unterschiedliche Eigenschaften. Einmal Width (Square) und Radius (Circle). Das sind Eigenschaften, die zwar die konkreten Klassen kennen aber Shape nicht:
Shape s1 = new Square(10, Color.BLUE); Console.WriteLine(s1.Width); // funktioniert nicht, da wir angebenen haben, dass s1 ein Shape-Objekt ist und Shape Width nicht kennt. Square s2 = s1; Console.WriteLine(s2.Width); // funktioniert, da s1 ja ein Square ist und wir sagen, dass s2 ein Square ist.  

Inzwischen schreibt man auch nicht mehr:
Square square = new Square(...); sondern:
var square = new Square(...); und überlasst den Kompiler den Rest. Die Angabe, um welchen konkreten Datentypen es sich handelt, ist nur eine doppelte Information, da wir mit new Square(...) schon den Datentyp kennen.

Das Thema hat absolut nichts mit Boxing und Unboxing zu tun, denn Boxing und Unboxing ist was anderes. Boxing und Unboxing wird verwendet, um Wertetypen (integer, double, ...) in Objekte zu wandeln (boxing) und von Objekten wieder zurück in Wertetypen (unboxing). Beispiel für Boxing:
int i = 123; object o = i; // boxing Beispiel für Unboxing:
o = 123; i = (int)o; // unboxing So etwas wird verwendet, wenn man z.B. eine Liste mit unterschiedlichen Datentypen hat:
var list = new List<object>(); In diese Liste kann dann alles reingeschrieben werden. Sei es z.B. Strings oder Integers.
Das Thema, was @redstav anspricht, ist "Vererbung" und Vererbung ist die Haupteigenschaft der Objektorientierung.
Abstrakte Klassen können nicht instanziert werden. Sie können nur vererbt werden, wie in dem Beispiel. Mit abstrakten Klassen können nämlich Grundgerüste geschaffen werden, die dann mit den Subklassen verfeinert werden können. Das Grundgerüst garantiert uns, dass die Subklassen die Eigenschaften und Methoden der abstrakten Klasse besitzt.
Dein Beispiel finde ich aber nicht so toll, da es die abstrakten Klassen schlecht veranschaulicht. Ich versuche es mal mit einem anderen Beispiel: Angenommen wir wollen geometrische Figuren auf dem Bildschirm malen. Wir haben ein Quadrat und ein Kreis und wollen sie als Klassen abbilden. Beide Figuren sollen später mit einer Farbe ausgefüllt werden und sollen eine Methode besitzen, die dafür sorgt, dass die Figur auf dem Bildschirm gemalt wird. Fangen wir naiv an:
public class Square { public double Width { get; } public Color Color { get; } public Square(double width, Color color) { this.Width = width; this.Color = color; } public void Paint() { // Malt Quadrat auf den Bildschirm } } public class Circle { public double Radius { get; } public Color Color {get; set;} public Square(double radius, Color color) { this.Radius = radius; this.Color = color; } public void Paint() { // Malt Kreis auf den Bildschirm } } Nun haben wir zwei tolle Klassen. Nun kommt die Vererbung ins Spiel: Wir sehen, dass der Aufbau beider Klassen dort recht identisch ist. Also können wir eine Grundgerüst - also eine abstrakte Klasse - bauen:
public abstract class Shape { public Color Color {get; set;} public Square(Color color) { this.Color = color; } public abstract void Paint(); } public class Square : Shape { public double Width { get; } public Square(double width, Color color) : base(color) { this.Width = width; } public override void Paint() { // Malt Quadrat auf den Bildschirm } } public class Circle : Shape { public double Radius { get; } public Circle(double radius, Color color) : base(color) { this.Radius = radius; } public override void Paint() { // Malt Kreis auf den Bildschirm } } Square und Circle besitzen nun durch die Vererbung die Eigenschaften von Shape. Mit der abstrakten Paint()-Methode geben wir dann noch zusätzlich an, dass die Methode zwar in den Subklassen zur Verfügung steht aber die konkrete Implementierung in den Klassen Geschehen muss. So wird dann garantiert, dass alle Klassen, die von Shape erben, auch die Paint()-Methode besitzen. Dies ist jetzt nämlich vom Vorteil, denn wir wollen ja geometrische Figuren auf dem Bildschirm zeichnen. Derjenige, der jetzt dafür sorgt, dass die Figur auf dem Bildschirm gezeichnet wird, muss nämlich nicht wissen, ob es nun ein Quadrat oder Kreis ist, sondern muss nur wissen, dass sie vom Typ Shape sind:
public class Screen { public void Paint(Shape shape) { shape.Paint(); } } Screen screen = new Screen(); Square square = new Square(12.5, Color.RED); Cirlce circle = new Circle(10, Color.BLUE); screen.Paint(square); screen.Paint(circle); Die Paint()-Methode in der Screen-Klasse muss also nicht den konkreten  Datentyp (Square oder Circle) wissen (ansonsten müssen wir jeden Typ eine eigene Methode schreiben), sondern muss nur wissen, dass die Klasse vom Typ Shape sein muss, um die Paint-Methode aufrufen zu können.
In den Klassen Square und Circle erkennt man auch, dass beide zwar vom Typ Shape sind aber beide haben unterschiedliche Eigenschaften. Einmal Width (Square) und Radius (Circle). Das sind Eigenschaften, die zwar die konkreten Klassen kennen aber Shape nicht:
Shape s1 = new Square(10, Color.BLUE); Console.WriteLine(s1.Width); // funktioniert nicht, da wir angebenen haben, dass s1 ein Shape-Objekt ist und Shape Width nicht kennt. Square s2 = s1; Console.WriteLine(s2.Width); // funktioniert, da s1 ja ein Square ist und wir sagen, dass s2 ein Square ist.  

Wie wäre es einfach mit einer Gruppe in einem der unzähligen Messenger? Wenn einer was schreibt, bekommen dies auch alle mit.

Wie wäre es einfach mit einer Gruppe in einem der unzähligen Messenger? Wenn einer was schreibt, bekommen dies auch alle mit.

Ich würde mal behaupten, dass man privat viel mehr Mittel zur Verfügung hat, als beruflich, da beruflich es um die Wirtschaftlichkeit geht. Da hat man nun mal nicht 4 Tage Zeit, um sich mal ein neues Framework oder eine neuen Webserver anzuschauen. Wenn es ein Problem gibt, dann muss es schnell gelöst werden und nicht schön. Also verwendet man die alten Paradigmen und Techniken weiter, weil die jeder kennt und zur Routine gehören. Da können die Paradigmen und Techniken auch ruhig veraltet und schlecht seien aber so hat man es dann immer gemacht und so versteht es auch jeder. Privat hat man aber die Zeit, mal andere Wege für ein Problem auszuprobieren. Wer sich also privat nicht weiterbildet, wird schnell zu den Entwicklern gehören, die den Anschluss verpasst haben.

Man setzt doch keine Pattern ein, damit man hinterher sagen kann, dass man Patterns benutzt hat.
Man setzt Patterns ein, weil man sie für ein bestimmtes Problem als nützlich erachtet hat und man stößt mit der Zeit auf die Patterns, wenn man nach Lösungen für bestimmte Probleme sucht. Niemand setzt sich hin und lernt ein Buch über Design Patterns auswendig. Es ist aber evtl. hilfreich sich ein Buch zu kaufen und mal darin zu stöbern.

Man setzt doch keine Pattern ein, damit man hinterher sagen kann, dass man Patterns benutzt hat.
Man setzt Patterns ein, weil man sie für ein bestimmtes Problem als nützlich erachtet hat und man stößt mit der Zeit auf die Patterns, wenn man nach Lösungen für bestimmte Probleme sucht. Niemand setzt sich hin und lernt ein Buch über Design Patterns auswendig. Es ist aber evtl. hilfreich sich ein Buch zu kaufen und mal darin zu stöbern.

https://www.govdata.de/
http://opendata.cern.ch/
Aber sicher, dass du nicht "Big Data" einfach mit "große relationale Datenbank" gleichsetzt?
 

https://www.govdata.de/
http://opendata.cern.ch/
Aber sicher, dass du nicht "Big Data" einfach mit "große relationale Datenbank" gleichsetzt?
 

DevOps ist auch ein recht neuer Begriff, der sich erst mal etablieren muss, da viele Firmen mit diesem Begriff noch nicht viel anfangen können und so nach und nach begreifen müssen, wozu DevOps benötigt wird. Den Begriff gibt es auch erst seit 4 Jahren und Deutschland gehört auch nicht zu den schnellsten IT-Ländern. Ich gehörte damals auch zu den ersten Mechatronikern auf den Arbeitsmarkt. Damals kannte den Begriff auch niemand. Nicht mal die Firmen. Die haben entweder einen Schlosser oder Elektriker gesucht. Damals musste ich den Firmen noch erklären, was eigentlich ein Mechatroniker ist oder haben sich selbst erst mal erkundigt und waren immer wieder erstaunt darüber, dass den es Beruf Mechatroniker gab, da man sich nicht vorstellen konnte, dass man zwei Berufe in einem zusammengefügt hat. Heute ist der Begriff allgegenwärtig und hat z.B. den Beruf Schlosser gänzlich ersetzt.
Deutschland ist auch noch mehr ein Land der Monolithen. Also ein großer Haufen Code, der alles kann, der noch On-Premise installiert wird. Außerdem ist hierzulande noch das Pflichten- und Lastenheft gegenwertig. Da ist CI/CD noch nicht so wichtig. Wenn man aber in Richtung agiler Softwareentwicklung denkt und den Kunden immer ein vollständiges Produkt zur Verfügung stellen möchte, dann wird CI/CD immer wichtiger und wir merken, dass es in unserem Umfeld (Banken) dies immer mehr zu einem Thema wird, da auch Banken immer mehr dazu verpflichtet werden, die Systeme auf den aktuellen Stand zu aktualisieren und sollen ihre individuelle Datenverarbeitung (IDV) abbauen. Da kommen dann inzwischen auch Themen wie SaaS oder FaaS.
Und wie @bigvic schon sagte, wenn man deine Suche als Maßstab nimmt, dann wären auch FISIs eine Nische, da 10 mal so viele Entwickler gesucht werden, wie Systemintegratoren.
Die Frage ist auch: Wie viele Personen für DevOps benötigt ein Unternehmen? Man benötigt vielleicht 40 Entwickler aber ggf. kommt man auch mit 3 DevOps aus. Das Team, dass bei uns mit CI/CD angefangen hat, besteht aus zehn Entwicklern und aus einer Person für DevOps. Wir dachten zuerst auch, dass dies die Entwickler mitübernehmen könnten aber es stellte sich heraus, dass es zu einer Vollzeitbeschäftigung wurde. Natürlich werden nicht so viele Personen für DevOps gesucht, wie für die Softwareentwicklung aber dennoch werden sie früher oder später benötigt.