Wir stehen kurz vor dem Abschluss eines weiteren Jahrzehnts Open Source und was für eine lange, seltsame Reise es war. Wenn man sich die Vorhersagen von 2009 ansieht, hat niemand die geringste Ahnung, dass GitHub die Softwareentwicklung für immer (und für alle) ändern würde oder dass Microsoft vom Open-Source-Paria zum weltweit größten Anbieter oder zu einer Vielzahl anderer dramatischer Änderungen übergehen würde wurde in einem Jahrzehnt zur neuen Normalität, die alles andere als normal war.

Wir sind jetzt alle offene Sourcing-Unternehmen, während wir das Jahrzehnt abrunden. Lassen Sie uns auf einige der wichtigsten Open Source-Innovationen zurückblicken, die uns hierher gebracht haben.

Eine wolkige Zukunft

Open Source machte natürlich vor 2010 Schlagzeilen, aber viele der Open Source-Nachrichten waren damals „Freie Software“ vs. „Open Source“ -Religiöse Kriege und Klagen gegen Linux. Um Open-Source-Software auszuführen, haben Sie immer noch die IT angerufen, um Server bereitzustellen (oder ein Ersatzlaufwerk verwendet, das gerade zufällig unter Ihrem Schreibtisch lag). Die Wolke hat das alles verändert.

Plötzlich mussten Entwickler keinen Hall-Pass von der IT erhalten, um ihren Open Source-Code auszuführen. So wie Open Source Entwickler vom Kauf / der gesetzlichen Genehmigung befreit hat, hat auch die Cloud die Entwickler von der Reibung befreit, die der Hardware innewohnt.

Die Wolke war jedoch nur der Wegbereiter. Wie Corey Quinn hervorhebt, ist die Infrastruktur zu „Open Source“ geworden, allerdings nicht, weil die Clouds selbst unter einer Open Source-Lizenz verfügbar sind: „Sie läuft auf Clouds, aber ich kann mir einen Terraform-Plan oder eine serverlose Konfiguration von GitHub holen und habe eine Es läuft, um es fast augenblicklich zu testen. “

Open Source-Lizenzen und der Swipe-and-Go-Zugriff auf Cloud-Hardware haben die Produktivität von Entwicklern in einer Weise gesteigert, die Anfang 2010 möglicherweise nur schwach sichtbar war (schließlich wurde AWS 2006 gestartet), die jedoch erst bis in das Jahrzehnt hinein umgesetzt wurde.

Es ist Git ganz unten

„Das größte Ereignis, das Open Source im letzten Jahrzehnt widerfahren ist, ist die Einführung der Pull-Anfrage durch GitHub“, erklärt Tobie Langel. „GitHub bot Open Source-Sichtbarkeit und verringerte die Voraussetzungen für die Zusammenarbeit um eine Größenordnung.“

Diese Zusammenarbeit war immer das Herzstück des Open-Source-Versprechens, aber erst, als GitHub den sozialen Aspekt der Codierung freigeschaltet hat, wurde sie Realität.

Wie Michael Uzquiano argumentiert: „Wir hatten zuvor Versionskontrolle, aber GitHub / Lab machte es wirklich einfach, Code zu teilen, Dinge auszuprobieren und Ideen einzubringen. Kommentare, Probleme, Genehmigung – das Versprechen, dass Code offen ist, wurde wirklich erfüllt. “Git wurde im letzten Jahrzehnt nicht geboren, aber wie die Cloud boomte es erst in den 2010er Jahren.

Docker und die Containerrevolution

Wie die Versionskontrolle und Git wurden Container nach 2010 nicht neu geprägt. Tatsächlich tauchte die Idee für Container bereits 1979 mit Chroot auf (obwohl Samen schon früher gepflanzt wurden).

Doch wie Steven Vaughan-Nichols behauptet, hat Docker die Container wirklich zum Leben erweckt: „Docker, genauer gesagt, Docker Tech hat Container von einer obskuren Technologie zu einer tragenden Säule des heutigen Software-Konsums gemacht. Es hat alles verändert. “

Alles? Ja, zumindest für die Entwicklung von Unternehmensanwendungen, und nicht, weil es eine coole neue Art ist, über Virtualisierung nachzudenken. Wie Gordon Haff erklärt, waren „Pre-Docker / Kubernetes-Container nur eine andere Partitionierungstechnik.“

Die eigentliche Magie begann, als Docker die Entwicklererfahrung nagelte, und von da an fuhr er fort: „Die Dinge sind in den Schneebällen“, was zu einer vollständigen Neuerfindung der CI / CD-Pipeline und mehr führte. Vor einem Jahrzehnt hatte noch niemand von Docker und Kubernetes gehört. Im vergangenen Monat waren mehr als 13.000 Menschen auf der KubeCon 2019 angereist, um diese moderne Anwendungswelt zu erkunden, die Docker mitgestaltet hat.

Datenwissenschaft wird zum Mainstream

Big Data war schon immer ein Traum für „den Rest von uns“ (d. H. Unternehmen, die nicht Google sind), und vor 2010 wurden ernsthafte Anstrengungen unternommen, um es zu verwirklichen. Wir haben Data Marts seit den 1970er Jahren, Business Intelligence etwas später, und Roger Magoulas hat 2005 sogar den Begriff „Big Data“ geprägt.

Aber keiner von ihnen hat wirklich vorausgesehen, wie groß diese Daten sein könnten und wie kritisch Datenwissenschaftler und Dateningenieure werden würden, bis weit in das Jahrzehnt hinein, in dem Apache Hadoop (2008 erstellt) auf den Markt kam und dann schnell verdrängt wurde durch eine Welle von NoSQL-Datenbanken und andere Open-Source-Infrastruktur.20

Heutzutage ist die Infrastruktur, in der große Datenmengen gespeichert und gestreamt werden, hauptsächlich Open Source.

Ob moderne Datenbanken wie MongoDB, die das Arbeiten mit unstrukturierten Daten erleichtern, oder verschiedene Tools wie Apache Kafka, die zum Verschieben von Daten verwendet werden, Open Source die moderne Datenwissenschaft ermöglichten, und fast alles geschah in den letzten 10 Jahren.

Darüber hinaus sind die Tools, mit denen wir Daten analysieren, zunehmend Open Source. Tatsächlich war ein Großteil der Werkzeuge (wie TensorFlow) von Tag 1 an Open Source, nicht ein Hagel Mary! Pass von einem proprietären Anbieter, der versucht, das schwindende Schicksal von t wiederzubeleben

Seien wir ehrlich. Angesichts der Vielzahl von Cloud-nativen Datenbanken für spezielle Zwecke, die wir in Produktion geben, malen wir uns in eine Ecke.

Dies ohne Rücksicht darauf, wie wir diese Datenbanken auf eine Weise verwenden sollten, die einen einfachen Zugriff und ein leichtes Verständnis der Daten ermöglicht. Heutzutage sind sie in der Regel an Anwendungen gekoppelt und verfolgen einen taktischen und keinen strategischen Zweck.

Dies ist nicht der Zweck von Daten und nicht das Versprechen der Cloud. Denken Sie daran, dass Daten in der Cloud in unseren Köpfen aufgebaut wurden, um den Zugriff auf und die Zentralisierung von Daten zu erleichtern. Schließlich könnten wir „wunderbare Dinge mit unseren Daten machen“.

Dies bedeutet nicht, dass die Beschaffung und der Betrieb von Daten und Datenbanken teuer geblieben sind. Das allein war ein großer Vorteil von Public Clouds.

Dank der wundervollen Welt der On-Demand-Cloud-Infrastruktur können Sie von „Datenbank benötigen“ zu „Datenbank haben“ innerhalb eines Tages oder weniger wechseln.

Die einfache Beschaffung von Cloud-nativen Datenbanken und damit der Aufbau neuer Datenbanken hat jedoch zu einem Problem mit der Datenkomplexität geführt, das einige wesentliche Nachteile mit sich bringt:

In der Regel gibt es kein gemeinsames Verständnis aller Unternehmensdaten und des Kontexts dieser Daten. Die Daten sind immer noch weitgehend isoliert, vielleicht sogar noch schlimmer als vor 10 Jahren, als unsere Reise in die öffentliche Cloud begann.
Jetzt sind wir mit unbeabsichtigten Konsequenzen konfrontiert, z. B. mangelndem Verständnis für den Umgang mit Sicherheit, Datenverwaltung oder sogar der Nutzung einer „einzigen Quelle der Wahrheit“.

Wir haben laufende Projekte, die sich mit dem Problem der Datenkomplexität befassen, wie die Linked Open Data Cloud. Die Linked Open Data Cloud bietet eine lose gekoppelte Sammlung von Daten, Informationen und Wissen, auf die jeder Mensch oder jede Maschine mit Zugang zum Internet zugreifen kann.

Ziel ist es, eine vom Web bereitgestellte Abstraktionsschicht zu erstellen. Es ermöglicht sowohl den einfachen als auch den anspruchsvollen Lookup-orientierten Zugriff mit der SPARQL-Abfragesprache oder mit SQL, um den Zugriff auf strukturierte und unstrukturierte Daten auf die gleiche Weise zu ermöglichen wie beim Zugriff auf Webseiten, um auf Bild- und Textseiten zuzugreifen, seit das Web gestartet wurde.

Natürlich bieten auch eine Reihe von Technologieanbietern Lösungen wie Stammdatenverwaltung, Datenvirtualisierung und andere Technologien an, mit denen Sie komplexe Daten auf verbesserte Weise verwalten können. Mit anderen Worten: Bereitstellung von Datensemantik und Metadatenverwaltung außerhalb der Datenbanken, Cloud oder nicht.

Ich verstehe jetzt, dass dieser Ansatz für die Verwaltung von Cloud-, Cross-Cloud- oder Hybrid-Cloud-Datenbanken nicht skalierbar oder altersgemäß ist. Bei der Betrachtung der aktuellen Anforderungen sowie in naher oder ferner Zukunft werden die Daten komplexer und technologisch vielfältiger, wenn man das rasante Innovationstempo berücksichtigt.

Der Versuch, die heute verwendeten Ansätze und Tools zu nutzen, wird die Komplexität erhöhen, bis die Systeme schließlich zusammenbrechen. Denken Sie nur an die Anzahl der Tools in Ihrem Rechenzentrum, die Sie heute dazu veranlassen, sich die Frage zu stellen: „Was haben sie gedacht?“ In der Tat haben sie ähnlich gedacht wie heute, einschließlich der Suche nach taktischen Lösungen, die letztendlich nicht das bieten Wert, den sie einmal hatten – und in einigen Fällen einen negativen Wert liefern.

Ich habe einen langen Weg zurückgelegt, um Ihnen eine Antwort zu geben, aber während ich darüber nachdenke, wie wir dieses Problem lösen, scheint ein Ansatz immer wieder als die wahrscheinlichste Lösung aufzutauchen. In der Tat wurde es in verschiedenen akademischen Kreisen herumgetrampelt. Es ist der Begriff der Selbstidentifizierung von Daten.

Product Roadmap-Software unterstützt Software-Produktmanager bei wichtigen Planungsaufgaben und kommuniziert Ziele und Status mit Mitgliedern des Projektteams und Interessengruppen.

Mithilfe eines Produkttools können Teams Strategien festlegen, Ziele priorisieren, die zu erledigende Arbeit planen und alle Mitarbeiter über den gesamten Produktlebenszyklus hinweg synchronisieren.

Alle Projektinformationen werden in einem einzigen Dashboard zusammengefasst.

Der Markt für Produkt-Roadmap-Software steckt noch in den Kinderschuhen, gewinnt jedoch an Dynamik und zieht sowohl Start-up-Unternehmen als auch etablierte Tool-Anbieter an.

Entwickler haben jetzt viele Roadmap-Tools zur Auswahl. Hier sind einige.

Airfocus

Mit Airfocus können alle Arten von Softwareprodukten entwickelt werden. Airfocus hat gelobt, dass Nutzer einfach keine „umständlichen Tabellenkalkulationen und Darmentscheidungen“ einhalten müssen.

Benutzer können bewerten und bestimmen, auf welche Bereiche sie sich konzentrieren müssen. Roadmap- und Priorisierungsvorlagen sind enthalten. Algorithmen berechnen Prioritäten und weisen sie visuell zu, damit Benutzer fundiertere Entscheidungen treffen können.

Airfocus berücksichtigt agile Konzepte und bietet eine agile Roadmap und Priorisierungsvorlage. Darüber hinaus stehen mobile Apps zur Verfolgung von Projekten zur Verfügung. Sie können eine kostenlose Testversion bei Airfocus.io starten.

Aha!

Aha! Ist der Meinung, dass es gut ist zu wissen, wohin Sie wollen, bevor Sie mit dem Bau beginnen. Das Unternehmen definiert eine Roadmap einfach als visuellen Plan und besteht darauf, dass jedes Team, das sinnvolle Arbeit leistet, einen Plan hat. Die SaaS-Anwendung von Aha bietet die folgenden Funktionen:

Erstellen und teilen Sie schnell visuelle Roadmaps.
Reihe von Unternehmensstrategie.
Ideen festhalten.
Definieren Sie Features und erstellen Sie Designdetails neu.
Priorisieren Sie die Anforderungen an Wirkung und Aufwand.

Aha! kann jede Entwicklungsmethode unterstützen, auch agil. Es lässt sich in mehr als 30 Tools integrieren, von GitHub und Jira bis zu Slack und Salesforce. Eine kostenlose Testversion ist bei Aha.io erhältlich.

Craft.io

Diese agile SaaS-App bietet eine umfassende Produktmanagementlösung, die mehrere Phasen abdeckt, einschließlich Strategie- und Rollenplanung. Craft.io lässt sich in Tools wie Jira und GitHub integrieren und dient so als ein einziges Aufzeichnungssystem, mit dem Produktmanager anhand aller verfügbaren Informationen Entscheidungen treffen können. Es werden verschiedene Ansichten angeboten. Zum Beispiel eine Tabellenansicht oder eine Kanbansicht. Die Sprintplanung wird ebenfalls unterstützt. Das Entwicklungsteam erhält im Verlauf der Arbeit automatische Updates.

Monday.com

Diese SaaS-Anwendung unterstützt den Produktlebenszyklus mit Schritten aus der Produktplanung. Monday.com wird als agile Software „für Entwickler und Nicht-Entwickler“ bezeichnet, die mit Methoden wie Scrum oder Kanban für jedes Team in jeder Branche verwendet werden kann.

Mit Benachrichtigungen und Echtzeitberichten können Benutzer den Fortschritt auf der Roadmap verfolgen und sich auf das Wesentliche konzentrieren. Andere Fähigkeiten umfassen:

• Planen, verfolgen und zusammenarbeiten in einem Tool.
• Vorlagen für Projekt-Roadmap, Sprint-Management und Bug-Tracking.
• Verwalten Sie Geschichten, Aufgaben und Fehler in einem einzigen Board.
• Integration mit Tools wie GitHub und PagerDuty.
• Produktplatine

Productboard ist ein Cloud-basiertes Produktmanagementsystem, das Ideen, Anforderungen und Feedback an einem Ort vereint. Mit Productboard können Benutzer nicht nur Produkt-Roadmaps für ihre Kunden freigeben. Hauptmerkmale sind:

Agiles Roadmapping bietet Flexibilität und automatische Updates, wenn sich Pläne ändern.
Übergeordnete Planung, die Prioritätsfunktionen unterstützt und Ziele definiert.
Ein Portal zum Austausch von Plänen und Informationen zur Bereitstellung von Feedback für die nächste Iteration.

We all made it: grab a cookie when Mama was not looking, drank a bit too much wine for dinner and left the car in a parking lot after the meter ran out.

We even walked around Deadman’s bend a bit too fast. And yes, we’ve all violated any number of key programming rules. Those who all agree are bad. And we secretly liked it.

We have come to terms with the rules of good programming, written code that is totally bad – and we have lived. There were no flashes from the programming gods. Our desktops have not exploded. Our code was compiled and shipped, and customers seemed satisfied.

This is because poor programming is not in the same league as licking an electric fence or pulling a tiger’s tail. Mostly it works. The rules are more common guidelines or stylistic suggestions, not directives that must be obeyed, or the code death will follow. Sure, your code could be ridiculed, possibly even public. The fact that you oppose conventions adds a little to the thrill, even if you accidentally undermine what (usually) corresponds to the social customs of a pleasant code.

Sometimes, for reasons of complexity, it is better to break the rules. (Shhhh!) The code comes out cleaner. It can even be faster and easier. The rules are usually a bit too broad, and a skilled programmer can improve the code by breaking it. Do not tell your boss, but sometimes it makes sense to code your own way.

What follows is a list of nine rules that some consider to be unassailable, but many of us break frequently, both with success and pleasure.

Bad Programming Habit # 1: Copy

It is wrong to do this at school. At work, the rules are not so clear. There are certainly some code blocks that should not be stolen. If it’s proprietary code, do not fold it into your stack, especially if it’s marked with a copyright notice. Write your own version. You will be paid for it.

The more difficult question comes when the original creator wants to share. Maybe it’s in one of these online program forums. Maybe it’s open source code with a license (BSD, MIT) that allows you to use one or three functions. There is no legal reason to stop you. And you are paid to solve problems and not reinvent the wheel.

Mostly the advantages of copying are convincing and the disadvantages can be limited with a little care. At least one train of thought has been applied to the code you receive from a reputable source.

The original author sought a solution and found something. The loop invariants and the data flow have been worked out.

The tricky questions are whether there are some undetected errors or other assumptions about the role or the underlying data.

Maybe your code mixes in null pointers, while the original code never checked them. If you can fix the issues, your boss seems to be supported by two programmers. It’s a couple programming without the chic desks.

Bad Programming Habit # 2: Non-working code

In den letzten zehn Jahren ist das Funktionsparadigma aufgestiegen.

Die Experten für die Erstellung Ihres Programms aus verschachtelten Funktionen zitieren gerne Studien, die zeigen, wie sicherer und fehlerfreier der Code ist als die älteren Variablen- und Schleifenstile, die auf jede Art und Weise aneinandergereiht sind, die den Programmierer glücklich machen.

Die Anhänger sprechen mit dem Eifer der wahren Gläubigen und verurteilen in Code-Überprüfungen und Pull-Anfragen nicht-funktionale Ansätze. Sie haben vielleicht sogar Recht mit den Vorteilen.

Aber manchmal muss man nur eine Rolle Klebeband herausholen. Wunderbar entwickelter und elegant geplanter Code braucht Zeit, nicht nur um sich etwas vorzustellen, sondern auch um ihn zu konstruieren und später zu navigieren. Alle diese Schichten erhöhen die Komplexität, und Komplexität ist teuer.

Entwickler von schönem funktionalem Code müssen vorausplanen und sicherstellen, dass alle Daten auf geeigneten Wegen weitergeleitet werden. Manchmal ist es einfacher, eine Variable zu erreichen und zu ändern.

Vielleicht schreibe einen Kommentar, um es zu erklären. Sogar das Hinzufügen einer langen, krassen Entschuldigung zu zukünftigen Generationen im Kommentar ist schneller als das Neuarchitekturen des gesamten Systems, um es richtig zu machen.

Schlechte Programmiergewohnheit Nr. 3: Nicht standardmäßiger Abstand

Die meisten Leerzeichen in der Software wirken sich nicht auf die Leistung des Programms aus.

Abgesehen von einigen Sprachen wie Python, die den Abstand zur Angabe von Codeblöcken verwenden, haben die meisten Leerzeichen keine Auswirkung auf das Verhalten des Programms.

Even so, there are obsessive programmers who count them and insist they are important. One of them once told my boss in the most serious tone that I write „Non Standard Code“ and he can see it immediately. My sin? ESLint Space Infix Ops Rule violations by not inserting spaces on either side of an equals sign.