Anmelden
Die Zentrale des IT-Sicherheitsspezialisten Kaspersky in Moskau.
(Bild: dpa, Pavel Golovkin)
Die britische Zentrum für Cyber-Sicherheit NCSC (National Cyber Security Centre) hat Regierungsbehörden vor Anti-Virus-Software der in Moskau ansässigen Firma Kaspersky Lab gewarnt.
Britische Regierungsbehörden sollen nach Meinung des britischen Zentrums für Cyber-Sicherheit NCSC (National Cyber Security Centre) keine Anti-Virus-Software der in Moskau beheimateten Firma Kaspersky Lab einsetzen. Das geht aus einem Brief von NCSC-Chef Ciaran Martin an britische Minister hervor, der auf der Webseite des Zentrums veröffentlicht wurde. Zur Begründung hieß es, Russland habe die Absicht, die britische Regierung und entscheidende Infrastruktur des Landes anzugreifen.
Es gäbe "offensichtliche Risiken" hinsichtlich Anti-Virus-Software, die von ausländischen Firmen stamme. "Wir empfehlen daher, dass dort, wo ein Zugriff des russischen Staates auf Informationen ein Risiko für die nationale Sicherheit darstellen würde, kein in Russland ansässiges Anti-Virus-Unternehmen gewählt wird", schreibt Martin. Das Zentrum sei derzeit im Gespräch mit Kaspersky über ein Abkommen, damit die Sicherheit empfindlicher Daten gewährleistet werden könne. Kaspersky hat Spionage-Vorwürfe stets bestritten. Auf Anfrage der Deutschen Presse-Agentur hob ein Kaspersky-Sprecher am Samstag hervor, dass die Warnung weder an Privatnutzer noch an Unternehmen gerichtet sei.
(dpa) /
URL dieses Artikels:http://www.heise.de/-3907209
Links in diesem Artikel:[1] mailto:it@ct.de
Copyright © 2017 Heise Medien
Nachdem Reporter ohne Grenzen mit ihrer Klage gegen den BND-Datenstaubsauger vor deutschen obersten Gerichten erfolglos blieb, trägt die Organisation diese nun vor den Straßburger Gerichtshof für Menschenrechte.
Die Aktivisten von Reporter ohne Grenzen (ROG) lassen mit ihrer Klage gegen die "strategische Fernmeldeüberwachung" durch den Bundesnachrichtendienst (BND) nicht locker. Die zivilgesellschaftliche Organisation hat ihre Beschwerde gegen die Massenüberwachung[1] jetzt vor den Europäischen Gerichtshof für Menschenrechte (EGMR[2]) gebracht. Zuvor war sie mit einem einschlägigen Verfahren vor dem Bundesverwaltungsgericht weitgehend gescheitert[3]. Auch der Gang vor das Bundesverfassungsgericht[4] blieb erfolglos: Die Karlsruher Richter nahmen die entsprechende Verfassungsbeschwerde mit einem Beschluss von Ende April nicht zur Entscheidung an.
ROG wirft dem Auslandsgeheimdienst vor, im Zuge seiner heftig umstrittenen Überwachungspraktiken den E-Mail-Verkehr der Organisation mit ausländischen Partnern, Journalisten und anderen Personen ausgespäht zu haben. Es bei den Klagen vor allem um Befugnisse aus dem sogenannten G10-Gesetzes[5], das dem BND umfangreiche Eingriffe ins Fernmeldegeheimnis erlaubt, das in Artikel 10 Grundgesetz verankert ist. So dürfen die Spione etwa einen Datenstaubsauger einsetzen[6], um den internationalen Telekommunikationsverkehr mithilfe bestimmter Suchbegriffe und sonstiger Selektoren zu durchforsten.
BND ) </span>
Die bislang angerufenen obersten deutschen Gerichte sahen ihre Hände gebunden, da ROG nicht habe glaubhaft machen können, dass die Organisation selbst von der BND-Bespitzelung betroffen war. Der geforderte Nachweis ist wegen der Geheimniskrämerei bei dem Nachrichtendienst schwer zu erbringen. In der Klageschrift an den EGMR führt die Vereinigung nun an, dass der BND ihr Recht auf Achtung der Korrespondenz sowie des Rechts auf Meinungs- und Informationsfreiheit gemäß den Artikeln 8 und 10 der Europäischen Menschenrechtskonvention[7] verletzt habe. Die ausufernden Suchkriterien des Geheimdienstes führten zu einer durch den mutmaßlichen Zweck der Maßnahmen keinesfalls gedeckten Reichweite der Eingriffe.
Darüber hinaus macht Reporter ohne Grenzen geltend, in ihrem Recht auf wirksame Beschwerde verletzt worden zu sein. Der weitaus größte Teil der Betroffenen erfahre nicht einmal im Nachhinein etwas davon, "dass ihre E-Mails erfasst und durchsucht werden", schreibt die Organisation. Selbst die Allgemeinheit mit den jährlichen Berichten des Parlamentarischen Kontrollgremiums des Bundestags regelmäßig erst dann über Überwachungsmaßnahmen informiert, wenn sogar entscheidende Protokolldaten schon gelöscht worden seien. Klagen dagegen vor deutschen Gerichten seien unter den aufgeführten Umständen unmöglich.
"Die ausufernde Überwachungspraxis des BND stellt die Vertraulichkeit digitaler Kommunikation grundsätzlich in Frage und untergräbt damit eine Voraussetzung journalistischer Recherche", begründete ROG-Geschäftsführer Christian Mihr den neuen Schritt. Jetzt sei es an den Straßburger Richtern, "dem Grundrecht auf Rechtsschutz vor der anlasslosen und unverhältnismäßigen BND-Massenüberwachung endlich zur Geltung zu verhelfen". Parallel ist der Teil der ursprünglichen Klage gegen das vom BND geführte Metadaten-Analysesystem Veras[8] weiter anhängig; auch eine Verfassungsbeschwerde von Amnesty International gegen den Datenstaubsauger der Schlapphüte läuft noch[9].
Der EGMR beschäftigt sich parallel mit Klagen von Bürgerrechtlern und Nichtregierungsorganisationen[10] gegen die gegen die Internet- und Computerspionage des britischen Geheimdiensts GCHQ[11]. Zu den Beschwerdeführern gehören hier unter anderem Provider, Constanze Kurz vom Chaos Computer Club (CCC)[12] sowie Privacy International. Eine Anhörung dazu fand Anfang November statt[13], bei der die Richter die Hacking-Methoden der Londoner Behörde hinterfragten. Mit einem Urteil des Menschengerichtshof in diesen Fällen ist 2018 zu rechnen.
(Stefan Krempl) /
URL dieses Artikels:http://www.heise.de/-3907198
Links in diesem Artikel:[1] https://www.heise.de/meldung/NSA-Skandal-Reporter-ohne-Grenzen-klagt-gegen-BND-2732465.html[2] http://www.echr.coe.int/[3] https://www.heise.de/meldung/Bundesverwaltungsgericht-lehnt-Klagen-gegen-BND-teilweise-ab-3570480.html[4] https://www.heise.de/meldung/Verfassungsgericht-Reporter-ohne-Grenzen-klagt-gegen-BND-Ueberwachung-3642414.html[5] https://www.gesetze-im-internet.de/g10_2001/[6] https://www.heise.de/meldung/NSA-Ausschuss-Kanzleramt-will-BND-Datenstaubsauger-strenger-regulieren-3356342.html[7] http://www.echr.coe.int/Documents/Convention_DEU.pdf[8] https://www.heise.de/meldung/NSA-Ausschuss-BND-kann-Daten-zu-Kontaktpersonen-schier-unbegrenzt-sammeln-3538172.html[9] https://www.heise.de/meldung/Internetueberwachung-Amnesty-klagt-gegen-BND-Datenstaubsauger-3466588.html[10] https://www.heise.de/meldung/Neue-Klage-gegen-GCHQ-Hacking-vor-dem-Menschengerichtshof-3289446.html[11] https://www.heise.de/meldung/UK-Geheimdienst-Britisches-Gericht-billigt-weitgehendes-GCHQ-Hacking-3103064.html[12] https://www.heise.de/meldung/GCHQ-Ueberwachung-Buergerrechtler-klagen-in-Strassburg-1972227.html[13] https://netzpolitik.org/2017/anhoerung-beim-menschenrechtsgerichtshof-d%20ie-rechtswidrigkeit-der-massenueberwachung/[14] mailto:it@ct.de
Copyright © 2017 Heise Medien
Intels Management Engine (ME) auf dem Chip lässt sich bei Rechnern des Anbieters System 76 per Firmware-Update deaktivieren. Denn die ME war durch Sicherheitslücken ins Gerede gekommen.
Um Bedenken seiner Kunden wegen möglicher Sicherheitslücken oder Backdoors[1] auszuräumen, stellt der amerikanische Anbieter von Linux-Komplettsystemen System 76 ein Firmware-Update bereit, das die Intel Management Engine deaktiviert. Möglich macht dies das sogenannte HAP-Bit, das einen Betrieb als High Assurance Platform einleitet – und auf Betreiben der Sicherheitsdienste Eingang in den Code gefunden haben soll.
Intel baut die Management Engine seit über 10 Jahren in seine Chipsätze und System-on-Chip-Prozessoren ein. Die in der ME enthaltenen Funktionen ermöglichen bei bestimmten Chips unter anderem, einen Rechner aus der Ferne hochzufahren, auch wenn dieser ausgeschaltet ist. Umgehen kann man die ME eigentlich nicht, weil sie wesentliche Systemfunktionen steuert.
Doch bei der Suche nach Sicherheitslücken in der ME[2] entdeckten Experten der russischen Firma PTE auch eine Möglichkeit, die ME ganz abzuschalten. Das macht sich jetzt System 76 zunutze und erledigt dies durch ein Firmware-Update[3]. Der Code kommt bei den hauseigenen Rechnern zum Einsatz und ist auf Github frei verfügbar.
URL dieses Artikels:http://www.heise.de/-3907151
Links in diesem Artikel:[1] https://www.heise.de/ct/artikel/Tipps-zur-Intel-ME-Sicherheitsluecke-SA-00075-3704454.html[2] https://www.heise.de/ct/ausgabe/2017-20-Intel-ME-wohl-weitgehend-abschaltbar-3828734.html[3] http://blog.system76.com/post/168050597573/system76-me-firmware-updates-plan[4] mailto:js@ix.de
Copyright © 2017 Heise Medien
Um den Einsatz von Windows 10 rechtskonform und sicher zu gestalten, lässt der Bund für seine Verwaltung den sogenannten Bundesclient entwickeln. Über dessen Sicherheitseigenschaften schweigt sich das Bundesinnenministerium allerdings aus.
Mit dem Einsatz von Microsofts Betriebssystem Windows 10 in der Verwaltung stellen sich angesichts der hochgradigen Vernetzung des Systems zahlreiche Datenschutz- und -Sicherheitsfragen. Derzeit ist es beispielsweise nicht möglich, über Gruppenrichtlinien die Datenströme zwischen dem eigenen Rechner und den Microsoft-Servern vollständig zu kontrollieren, wie das Bayerische Landesamt für Datenschutzaufsicht (BayLDA) feststellte. [1]
Um doch einen sicheren Einsatz des von Microsoft periodisch aktualisierten Windows 10 in der öffentlichen Verwaltung zu ermöglichen, wird deshalb derzeit vom Informationstechnikzentrum Bund und dem IT-Dienstleister der Bundeswehr BWI ein spezieller „Bundesclient“ entwickelt. Dies entschied Mitte November der zuständige Lenkungsausschuss.
Der „Bundesclient“ ist ein Standard-IT-Arbeitsplatz, wie ihn das Bundeskabinett bereits im Mai 2015 im Rahmen eines Grobkonzepts zur IT-Konsolidierung Bund für die Bundesverwaltung beschlossen hat. Er wird ausschließlich für die Beschäftigten der Bundesverwaltung konzipiert und soll ab 2019 ersten Behörden zur Verfügung stehen. Dabei soll er für verschiedene Endgeräteklassen, so auch für die mobile Nutzung, entwickelt werden.
Das Bundesinnenministerium hat sich vertraglich bei Microsoft sogenannte Downgrade-Rechte zusichern lassen. Damit hat der Bund das uneingeschränkte Recht, ältere Versionen einzusetzen, auch wenn Microsoft ein unter dem Betriebssystem verfügbares Produkt durch eine neue Version ersetzt hat.
Entwickelt wird der Bundesclient von den IT-Dienstleistern des Bundes unter Einbeziehung des Bundesamtes für Sicherheit in der Informationstechnik (BSI) sowie der Bundesdatenschutzbeauftragten. Hierfür sollen mehrere Aufträge an verschiedene Unternehmen vergeben werden. Über den Umfang der geplanten Aufwendungen schweigt sich das Bundesinnenministerium aus. Gegenüber heise online teilte ein Sprecher mit: „Sie können nicht veröffentlicht werden, damit anstehende Ausschreibungen nicht beeinflusst werden.“
Zur Absicherung des Bundesclients wurde eine Sicherheitsinfrastruktur entworfen, über deren Einzelheiten das Bundesinnenministerium ebenfalls Stillschweigen bewahren will, „da die Kenntnis der konkreten Maßnahmen es unbefugten Personen erleichtern würde, zielgerichtet Sicherheitsmechanismen des Bundesclients anzugreifen.“ Es verspricht jedoch, dass eine Verarbeitung von Daten bis einschließlich „VS-Nur für den Dienstgebrauch“ ermöglicht werden soll. Die Entwicklung des Bundesclients und die Abnahme erfolgt im Einvernehmen mit dem BSI und nach Durchführung der erforderlichen Tests. Die Bundesdatenschutzbeauftragte ist im Moment nicht in den Abnahmeprozess involviert und hat kein Veto-Recht.
Das Thema Standardarbeitsplätze ist in der Verwaltung nicht neu. Der IT-Dienstleister Dataport, der die Verwaltung mehrerer Bundesländer mit IT versorgt, hat diese bereits seit 2005 im Portfolio und versorgt zurzeit rund 100.000 Arbeitsplätze. Auch andere IT-Dienstleister auf Landesebene haben Erfahrungen mit Standardarbeitsplätzen. Gegenüber heise online sagte Dataport-Geschäftsführer Johann Bizer, dass eine Standardisierung „grundsätzlich zu begrüßen“ sei. Er fügte aber hinzu: „Ich habe einen Erfahrungsaustausch mit dem Bund bereits mehrfach angeboten.“ Dieser sei sinnvoll, weil der Bund von den Erfahrungen, die die Landes-Dienstleister mit der Konzeption und dem Betrieb von Standardarbeitsplätzen gemacht haben, profitieren könnte.
Bei Dataport werden derzeit Windows-Arbeitsplätze sukzessive auf Windows 10 migriert. Sie müssen allerdings ohne die Online-Services auskommen, da sie analog zu dem Deployment-Modell von Dataport „vollständig abgeklemmt“ sind, wie Dataport versichert.
Die Entscheidung zwischen komfortablem Online-Zugang und datenschutzkonformen Betrieb müssen auch Privatbetriebe fällen, wie das IT-Magazin iX schon im Juni dieses Jahres feststellte [2]. Eine "restriktive Konfiguration ziehe erhebliche Nachteile im Alltagsbetrieb nach sich" war die Quintessenz eines Artikels zur Windows-10-Administration. Generell ist mit der Einführung von Windows 10 das Datenschutzniveau stark gesunken. [3]
URL dieses Artikels:
https://www.heise.de/ix/meldung/Bund-will-Windows-10-ueber-Bundesclient-sicher-nutzen-koennen-3907088.html
Links in diesem Artikel:
[1] http://www.lda.bayern.de/media/windows_10_report.pdf
[2] https://www.heise.de/ix/heft/Kollateralgenerve-3716760.html
[3] http://www.heise.de/ix/heft/Datenschleuder-3356982.html
[4] mailto:js@ix.de
Die Independent System Architecture (ISA) stellt Prinzipien für Microservices auf. ISA definiert grundlegende Eigenschaften von Microservices, die erhebliche Probleme aufwerfen, wenn sie nicht eingehalten werden.
Das Ziel ist, die fundamentalen Konzepte von Microservices darzustellen und nicht nur einen bestimmten Ansatz, Microservices umzusetzen, wie dies Self-contained Systems[1] (SCS) tun. SCS waren schon Thema eines anderen Blog-Beitrags[2].
Es gibt neun Prinzipien:
1. Das System ist in Module aufgeteilt. Module sind eine alte Idee. Das erste Prinzip stellt Microservices in diese Tradition. So wird deutlich, dass andere Modularisierungsansätze Alternativen zu Microservices sein können. Wegen des Modulbegriff treffen auch Konzepte wie Information Hiding auf Microservices zu. Microservices dürfen daher nicht von den Interna anderer Microservices abhängen. Beispiel: Wie Klassen in einem OO-System keine internen Daten anderer Klassen (Instanzvariablen) nutzen dürfen, so dürfen Microservices nicht Daten anderer Microservices direkt auslesen, indem sie beispielsweise auf die Datenbank-Schemata des Microservice zugreifen.
2. Die Module laufen als Docker-Container, Prozesse oder virtuelle Maschinen. Also würde ein Bestellprozess-Modul beispielsweise in einem eigenen Docker-Container laufen. Diese Implementierung unterscheidet ISA fundamental von anderen Modularisierungen und hat einige Vorteile. Beispielsweise können Module in unterschiedlichen Programmiersprachen geschrieben sein oder unabhängig voneinander deployt werden.
3. Die Architektur wird in die Mikro-Architektur, die nur einzelne Module betrifft, und die Makro-Architektur unterteilt, die das gesamte System umfasst. Die Makro-Architektur gibt die minimalen Regeln vor, um die langfristige Evolution sicherzustellen und zu garantieren, dass das System nach außen wie ein System erscheint. Die weiteren Prinzipien sind Teile der Makro-Architektur.
4. Die Integration der Module muss definiert sein. Die Module können synchron, asynchron oder auf der UI-Ebene integriert werden. Das ist notwendig, damit das System am Ende tatsächlich ein System ist und nicht etwa nur Module ohne Zusammenhalt.
5. Kommunikation beispielsweise per RESTful HTTP oder Messaging muss ebenfalls standardisiert sein, damit die Module miteinander kommunizieren können.
6. Jedes Modul hat eine eigene Continuous Delivery Pipeline. Die Module können prinzipiell unabhängig voneinander deployt werden, weil sie als Container umgesetzt sind. Mit einer getrennten Continuous Delivery Pipeline ist ein getrenntes Deployment auch tatsächlich möglich. Da die Pipeline vor allem Tests umfasst, müssen also insbesondere die Test der Module unabhängig voneinander sein.
7. Der Betrieb sollte standardisiert sein. Das betrifft zum Beispiel Logs, Monitoring, Konfiguration und Deployment. Die Standardisierung reduziert den Aufwand, weil so zwar die Anzahl der Containern steigt, aber sie zumindest einheitlich behandelt werden können.
8. Alle Standards sollen auf Ebene der Schnittstelle definiert sein. Eine Kommunikation per RESTful HTTP mit einem festen Datenschema oder ein bestimmtes Monitoring-System auf einem bestimmten Server sind Standardisierungen auf Ebene der Schnittstelle. Wenn die konkrete REST-Bibliothek oder eine Bibliothek für Monitoring vorgegeben wird, wird die Technologie standardisiert. Das schränkt die mit ISA gewonnenen Freiheiten ein. In einem Projekt kann sich natürlich dennoch ein einheitlicher Technologie-Stack durchsetzen und so Aufwände einsparen. Langfristig kann der Stack bei der Evolution des Systems durch einen anderen Stack abgelöst oder ergänzt werden, ohne die Standards zu verletzen. So kann der Technologie-Stack aktualisiert werden, und das System bleibt zukunftssicher.
9. Resilience ist die Fähigkeit eines Moduls, bei einem Ausfall eines anderen Moduls weiter zu funktionieren - gegebenenfalls mit schlechteren Ergebnissen. Das unterbindet Fehlerkaskaden, bei denen der Ausfall eines Moduls andere Module ebenfalls zum Ausfall bringt und so das gesamte System letztendlich ausfällt. Ebenso müssen Module damit umgehen können, dass sie auf einen anderen Server neu gestartet werden. Das erleichtert den Betrieb im Cluster, bei dem Module auf unterschiedlichen Servern laufen müssen und gegebenenfalls Server ausfallen oder gewartet werden müssen.
Dieser Blog-Beitrag bietet nur eine Einführung in die ISA-Prinzipien. Weitere Informationen finden sich unter isa-principles.org[3]. Insbesondere die Begründungen sind für ein besseres Verständnis interessant.
Die gesamte Website steht unter Creative Commons Attribution Share Alike. Der Quellcode der Website findet sich auf GitHub[4] wieder. Wer Verbesserungsvorschläge oder Kritik hat, kann einen Issue einstellen, einen Pull Request erstellen oder an der Diskussion[5] teilnehmen. Ebenso gibt es eine Präsentation[6], die man auch als PowerPoint[7] herunterladen kann und die ebenfalls unter Creative Commons Attribution Share Alike steht.
URL dieses Artikels:http://www.heise.de/-3889160
Links in diesem Artikel:[1] http://scs-architecture.org[2] https://www.heise.de/developer/artikel/Self-contained-Systems-ein-Architekturstil-stellt-sich-vor-3038718.html[3] http://isa-principles.org[4] https://github.com/ISA-Principles/isa-principles.org/[5] http://isa-principles.org/discussion.html[6] http://isa-principles.org/slidedeck/ISA.pptx[7] https://speakerdeck.com/isaprinciples/isa-principles
Copyright © 2017 Heise Medien
Das Implementieren von Bestell- beziehungsweise Bezahlprozessen innerhalb von Webanwendungen kann mitunter recht komplex sein. Die sogenannte Payment Request API[1], die momentan beim W3C ausgearbeitet wird und vor etwa einem Monat zusammen mit den Payment Method Identifiers[2] als "Candidate Recommendation" veröffentlicht wurde, soll hier Abhilfe schaffen.
Die API sieht vor, den Browser als Vermittler zwischen folgenden bei einem Bestellprozess involvierten Akteuren einzusetzen: dem Zahlungsempfänger (beispielsweise einem Online-Händler), dem Zahlungssender (also dem Käufer) und demjenigen, der die Hilfsmittel für eine Zahlung bereitstellt (Kreditkarte etc.).
Folgende Typen werden durch die API bereitgestellt:
Ob die API vom aktuellen Browser unterstützt wird, lässt sich innerhalb einer Website wie gewohnt über Feature Detection prüfen, beispielsweise durch Überprüfung auf das PaymentRequest-Objekt:
FreshRSS if (window.PaymentRequest) {
// Payment Request API wird unterstützt
} else {
// Payment Request API wird nicht unterstützt
}Momentan unterstützen lediglich Chrome, Opera und Microsoft Edge die API[3], in Firefox kann die API als experimentelles Feature über das Flag "dom.payments.request.enabled" unter "about:config" aktiviert werden.
Um eine Bezahlanfrage zu formulieren, erstellt man eine Instanz von PaymentRequest, wobei dem Konstruktor drei Konfigurationsobjekte als Parameter übergeben werden können:
const methodData = { /* siehe Listings unten */ };
const details = { /* siehe Listings unten */ };
const options = { /* siehe Listings unten */ };
const paymentRequest = new PaymentRequest(
methodData,
details,
options
);Über methodData lassen sich die zur Verfügung stehenden Bezahlmethoden angeben. Der Eigenschaft supportedMethods kann dabei ein Array von Kennzeichnern für unterstützte Bezahlmethoden hinterlegt werden:
// Konfiguration der Bezahlmethoden
const methodData = [
{
supportedMethods: ['basic-card'],
data: {
supportedNetworks: ['visa', 'mastercard'],
supportedTypes: ['debit', 'credit'],
}
}
];
Nähere Angaben zu der Bestellung wie etwa Identifikationsnummer einer Bestellung, die zu bestellenden Artikel, Versandkosten etc. lassen sich über das Konfigurationsobjekt details konfigurieren:
// Konfiguration der Bestelldetails
const details = {
id: 'order-123-12312',
displayItems: [
{
label: 'Summe',
amount: { currency: 'EUR', value: '25.00' },
},
{
label: 'Mehrwertsteuer',
amount: { currency: 'EUR', value: '4.75' },
},
],
shippingOptions: [
{
id: 'standard',
label: 'Standardversand',
amount: { currency: 'EUR', value: '5.00' },
selected: true,
},
{
id: 'express',
label: 'Expressversand',
amount: { currency: 'EUR', value: '11.00' },
},
],
total: {
label: 'Gesamtsumme',
amount: { currency: 'EUR', value: '34.75' },
},
};
Über das dritte Konfigurationsobjekt options lässt sich definieren, welche Informationen der Nutzer während des Bestellvorgangs eingeben muss, beispielsweise Name, E-Mail-Adresse oder Telefonnummer:
// Konfiguration der Pflichtangaben
const options = {
requestPayerEmail: true,
requestPayerName: true,
requestPayerPhone: true,
requestShipping: true,
};
Um eine Bezahlanfrage zu starten und damit den entsprechenden Dialog zu öffnen, verwendet man die Methode show() am PaymentRequest-Objekt. Zurück gibt die Methode ein Promise-Objekt, das erfüllt wird, wenn der Nutzer den Bezahlprozess über den Dialog abschließt. Innerhalb des darauf folgenden Callbacks lässt sich dann auf die vom Nutzer eingegebenen Daten zugreifen, üblicherweise um sie zur Überprüfung an den Server zu senden (im Folgenden durch den Aufruf von verify() symbolisiert).
// Hier normalerweise Überprüfung durch Server
const verify = (paymentResponse) => Promise.resolve(true);
Der Aufruf der Methode complete() teilt dem Browser anschließend mit, dass der Bezahlprozess abgeschlossen wurde. Als Parameter lassen sich hier die Werte "success" für eine erfolgreiche Bezahlung oder "failure" bei Auftreten eines Fehlers übergeben. Dem Browser steht es laut Spezifikation dann frei, ob er eine entsprechende Meldung anzeigt oder nicht.
paymentRequest.show()
.then((paymentResponse) => {
// Zugriff auf die vom Nutzer
// eingegebenen Daten.
const {
requestId,
methodName,
details,
shipping,
shippingOption,
payerName,
payerEmail,
payerPhone
} = paymentResponse;
// verify() als imaginäre Funktion, mit der
// die Bezahlanfrage mit der Serverseite überprüft wird
verify(paymentResponse).then((success) => {
if (success) {
console.log('Bezahlung erfolgreich durchgeführt');
return paymentResponse.complete('success');
} else {
console.error('Fehler bei Bezahlung');
return paymentResponse.complete('failure');
}
});
})
.catch((error) => {
console.error('Fehler:', error);
});
Die Payment Request API will Bestell- bzw. Bezahlprozesse innerhalb von Webanwendungen vereinfachen und vereinheitlichen. Wer die API heute schon testen möchte, kann den oben gezeigten Code in einem der zuvor genannten Browser ausführen. Anmerkungen und Verbesserungsvorschläge zur API kann man übrigens über die Issue-Seite[4] des entsprechenden GitHub-Projekts loswerden.
URL dieses Artikels:http://www.heise.de/-3694012
Links in diesem Artikel:[1] https://www.w3.org/TR/payment-request/[2] https://www.w3.org/TR/payment-method-id/[3] http://caniuse.com/#feat=payment-request[4] https://github.com/w3c/browser-payment-api/issues
Copyright © 2017 Heise Medien
Softwareentwicklung findet im Team statt und hat daher einen sozialen Aspekt. Aber wie viel Rücksicht sollte man darauf nehmen?
Für Technologieentscheidungen gibt es viele Einflussfaktoren. Ob es darum geht, serverseitig HTML zu erzeugen oder eine Single-Page App (SPA) zu entwickeln, eine NoSQL-Datenbank oder eine relationale Datenbank einzusetzen, Containerisierung oder Bare Metal zu nutzen: Neben der technischen Eignung beeinflussen auch soziale Aspekte solche Entscheidungen. Wenn alle anderen Faktoren gleich sind, ist die Technologie risikoärmer, mit der das Team bereits gearbeitet hat. Neben Erfahrung spielt auch Motivation eine Rolle: Technologien, die das Team gerne nutzen will, können eine bessere Wahl sein.
Interessant wird es, wenn der soziale Aspekt im Widerspruch zu anderen Aspekten steht. Schließlich haben die Technologien immer bestimmte Stärken und Schwächen. In einigen Situationen sind SPAs die bessere Wahl, in anderen serverseitiges HTML. Relationale Datenbanken und NoSQL-Datenbank sind in unterschiedlichen Situationen unterschiedlich sinnvoll.
Im Extremfall nutzt das Projekt eine unpassende Technologie und Architektur, weil die Team-Mitglieder die Technologie oder Architektur präferieren oder schon Erfahrungen damit haben. So werden die eigentlich passende Technologie und Architektur nicht umgesetzt. Sollte man auch in solchen Situationen so einen starken Fokus auf die soziale Seite der Entscheidung legen?
Hinzu kommt: Ein Pragmatic Prgrammer[1] sollte pro Jahr mindestens eine neue Programmiersprache lernen. Gilt das nicht noch viel mehr für Technologien oder gar Architekturkonzepte? Warum also solche Situationen nicht nutzen, um neue technische Skills zu erlernen?
Technologie- und Architekturentscheidungen haben soziale Aspekte. Diese spielen manchmal aber eine zu große Rolle. Ergebnis: Schlechte Technologiewahl, schlechte Architektur und eine vergebene Gelegenheit, Neues zu lernen.
Danke an meine Kollegen Frederik Dohr, Christoph Iserlohn, Tammo van Lessen, Till Schulte-Coerne, Michael Simons, Christian Stettler und Stefan Tilkov für das Feedback zu einer früheren Version des Blog-Beitrags.
URL dieses Artikels:http://www.heise.de/-3824481
Links in diesem Artikel:[1] https://en.wikipedia.org/wiki/The_Pragmatic_Programmer
Copyright © 2017 Heise Medien
Ein wesentliches Design-Prinzip unter Node.js ist es, den Code getreu dem Motto "small is beautiful" in möglichst kleine, wiederverwendbare Packages zu strukturieren. Bei komplexeren Projekten kann das jedoch schnell unübersichtlich werden, wenn für jedes Package ein eigenes Git-Repository zu verwalten ist. Das Tool "Lerna" verspricht Abhilfe.
Wer unter Node.js oder allgemein in JavaScript ein komplexes Projekt entwickelt und seinen Code getreu dem vorgenannten Motto in viele kleine Packages strukturiert, landet recht schnell bei 50, 100 oder noch mehr Packages. Verwaltet man jedes davon in einem eigenen Git-Repository, artet das schnell in viel Konfigurationsarbeit aus: sei es, um Abhängigkeiten untereinander zu verwalten, Build-Prozesse zu organisieren oder das Deployment zu npm zu steuern.
Aus diesen Gründen strukturieren Entwickler bekannter Frameworks wie Angular[1], React[2], Meteor[3] und Ember[4] oder bekannter Tools wie Babel[5] und Jest[6] ihren Code mittlerweile in sogenannten Monorepositories[7], kurz Monorepos oder auch Multi-Package-Repositories. Die Idee: Statt jedes Package in einem eigenen Git-Repository vorzuhalten, bündelt man zusammengehörige Packages in einem einzelnen Repository.
Die Vorteile liegen auf der Hand: Zum einen muss man sich nicht mit mehreren Git-Repositories "herumschlagen", zum anderen lässt sich der Build-Prozess für alle Module stark vereinfachen und, wie wir gleich sehen werden, auch das Deployment zur npm-Registry. Ein Tool, das hierbei hilft, ist Lerna[8].
Ursprünglich Teil von Babel[9], ist Lerna mittlerweile ein eigenständiges Node.js-Package und kann wie gewohnt über den Package Manager npm als globale Abhängigkeit installiert werden:
$ npm install -g lerna
Anschließend kann das Tool über den Befehl lerna aufgerufen werden, wobei eine Reihe verschiedener Parameter zur Verfügung stehen:
Ein Multi-Package-Repository definiert sich im Wesentlichen durch seine Struktur und über zwei globale Konfigurationsdateien: Zum einen über eine package.json-Datei, die Meta-Informationen für alle verwalteten Packages enthält, zum anderen über eine Konfigurationsdatei namens lerna.json, die wiederum Lerna-spezifische Meta-Informationen enthält. Die einzelnen Packages wiederum werden standardmäßig in einem Unterverzeichnis mit Namen packages einsortiert, sodass die Gesamtstruktur wie folgt aussieht:
multirepo/
node_modules/
packages/
package1/
node_modules/
src/
index.js
package.json
package2/
package3/
package4/
package5/
package6/
package.json
lerna.json
Diese Struktur kann man zwar manuell erzeugen. Alternativ steht aber auch wie oben schon erwähnt der Befehl lerna init zur Verfügung, der zumindest die beiden Konfigurationsdateien automatisch generiert:
$ git init multirepo
$ cd multirepo
$ lerna init
Dadurch wird zum einen das Modul Lerna als Abhängigkeit zu der package.json-Datei hinzugefügt (sofern dort noch nicht vorhanden) und zum anderen die Konfigurationsdatei lerna.json erzeugt. Zu Anfang sieht die Datei wie folgt aus und enthält die Versionsnummer der verwendeten Lerna-Bibliothek, eine Angabe darüber, unter welchem Verzeichnis die Packages liegen sowie eine Versionsnummer, die global für alle Packages gilt. Welche weiteren Konfigurationsmöglichkeiten es hier gibt, entnimmt man am besten der offiziellen Dokumentation[10].
{
"lerna": "2.0.0-beta.38",
"packages": [
"packages/*"
],
"version": "0.0.0"
}Die Struktur der einzelnen Packages in einem Multi-Package-Repositories unterscheidet sich nicht von einem Package, das als Single-Package-Repository verwaltet wird. Das heißt beispielsweise, dass jedes Package weiterhin über seine eigene package.json-Datei verfügt und darüber zum Beispiel auch seine eigenen Abhängigkeiten definiert.
Für Abhängigkeiten hingegen, die nur während der Entwicklung benötigt werden (Eintrag "devDependencies" in package.json) ist es in den meisten Fällen sinnvoll, diese in der globalen package.json eines Multi-Package-Repositories anzugeben.
Das hat mehrere Vorteile: zum einen ist auf diese Weise sichergestellt, dass alle Packages die gleiche Version einer verwendeten Abhängigkeit haben. Zum anderen reduzieren sich dadurch sowohl die Installationszeit als auch der verwendete Speicherplatz für die entsprechende Abhängigkeit, da sie – logisch – nur einmal für alle Packages (und nicht einmal für jedes Package) installiert wird.
Ein ebenfalls nützlicher Befehl ist lerna bootstrap. Dieser sorgt dafür, dass die Abhängigkeiten aller Packages installiert werden. Mit anderen Worten: Lerna ruft für jedes Package den Befehl npm install aus. Aber nicht nur das. Zusätzlich werden für alle Packages im Multi-Package-Repository, die als Abhängigkeit von einem anderen Package im Repository verwendet werden, symbolische Links erzeugt, was – Node.js-Entwickler werden das bestätigen – bei der Entwicklung enorm hilfreich ist. Zu guter Letzt wird dann noch für jedes Package der Befehl npm prepublish aufgerufen, wodurch die in den package.json-Dateien definierten "prepublish"-Skripte[11] ausgeführt werden.
Nimmt einem Lerna bis hierhin schon viel Arbeit ab, wird es bezüglich Deployment beziehungsweise Publishing noch besser. Der Befehl lerna publish sorgt dafür, dass die Versionsnummer für alle Packages, die sich seit dem letzten Release geändert haben, entsprechend hochgezählt wird. Dabei kann über einen kleinen Kommandozeilendialog ausgewählt werden, ob es sich um einen "Patch", einen "Minor Change", einen "Major Change" oder um einen "Custom Change" handelt (nett: Die jeweils neue Version wird in Klammern hinter der jeweiligen Auswahl angezeigt).
Aber nicht nur das: lerna publish sorgt weiterhin dafür, dass entsprechende Tags und Commits für die neue Version in Git erzeugt und alle Packages separat bei npm publiziert werden.
Die Bibliothek Lerna hilft bei komplexen JavaScript-Projekten, die aus mehreren zusammengehörigen Packages bestehen, den Überblick zu behalten: Sie erleichtert die Konfiguration des Build-Prozesses, die Verwaltung über Git und das Publishing zu der npm-Registry. Als Empfehlung sollte jeder Node.js-Entwickler, der mit komplexen Projekten oder einer komplexen Package-/Repository-Struktur zu "kämpfen" hat, bei Gelegenheit mal einen Blick riskieren. Eventuell lohnt sich ja der Umstieg.
URL dieses Artikels:http://www.heise.de/-3718109
Links in diesem Artikel:[1] https://github.com/angular/angular/tree/master/modules[2] https://github.com/facebook/react/tree/master/packages[3] https://github.com/meteor/meteor/tree/devel/packages[4] https://github.com/emberjs/ember.js/tree/master/packages[5] https://github.com/babel/babel/tree/master/packages[6] https://github.com/facebook/jest/tree/master/packages[7] https://github.com/babel/babel/blob/master/doc/design/monorepo.md[8] https://github.com/lerna/lerna[9] https://babeljs.io/[10] https://github.com/lerna/lerna/#lernajson[11] https://docs.npmjs.com/misc/scripts
Copyright © 2017 Heise Medien
Es gibt gute und schlechte Softwarearchitektur – so viel ist klar. Aber gibt es die optimale?
Was ist eine gute Softwarearchitektur? Ist langfristige Wartbarkeit ein Zeichen für eine gute Architektur? Für ein Start-up-Unternehmen ist langfristige Wartbarkeit nicht so wichtig. Wenn es nicht schnell einen ausreichenden Umsatz erzielt, dann wird es vom Markt verschwinden. Langfristige Wartbarkeit hilft erst danach.
Dann ist vielleicht Skalierbarkeit wichtig? Ein System für die Verarbeitung medizinischer Daten kommt vielen Anforderungen nach, die nichts mit Skalierbarkeit und Wartbarkeit zu tun haben. Die Daten müssen sicher sein. Nicht nur vor unberechtigtem Zugriff – sondern auch vor Hardware-Problemen, und sogar bei hoher Last dürfen keine Daten verloren gehen. Es muss protokolliert werden, welche Mitarbeiter welche Daten wann gesehen oder geändert haben. Diese Anforderungen gehen über eine einfach Sichtweise auf Sicherheit hinaus.
Eine wesentliche Aufgabe der Architektur ist, solche Anforderungen zu ermitteln. Wer die Anforderungen nicht kennt, kann sie wohl kaum erfüllen. Leider scheitern viele Architekturen schon an diesem Punkt. Erst auf Basis dieser Anforderungen kann man dann eine technische Lösung entwerfen. Also können Architekturen ohne diese Anforderungen keine guten technischen Lösungen werden.
Die Anforderungen lassen sich in Qualitätsszenarien festhalten. Sie beschreiben konkret, wie sich ein System verhalten soll. Ein Beispiel für ein Qualitätsszenario: "Ein neues Land muss im System unterstützt werden. Die Änderung kann in höchsten 10PT umgesetzt werden."
Eine Qualitätsbaum kann als Überblick dienen und hilft sicherzustellen, dass alle möglichen Kategorien erfasst worden sind. Die "arc42 Documentation"[1] zeigt, wie Qualitätsszenarien und Qualitätsbäume dargestellt werden können.
Am Ende ist jede Architektur wegen anderer Anforderungen individuell und auf den jeweiligen Kontext angepasst. Also gibt es keine allgemeingültigen Best Practices oder die optimale Architektur – sondern nur Lösungen für bestimmte Probleme. Aus denen muss sich der Architekt bedienen – und das macht natürlich auch Spaß!
Architekturen sind spezielle technische Lösungen. Also muss man die Anforderungen des Projekts kennen und dafür eine individuelle Lösung entwerfen. Qualitätsbäume und Qualitätsszenarien helfen.
URL dieses Artikels:http://www.heise.de/-3785166
Links in diesem Artikel:[1] http://docs.arc42.org/section-10/
Copyright © 2017 Heise Medien
Unternehmen wie Facebook leben von Software und entwickeln sehr große und komplexe Projekte. Wenn Vorgehen und Technologien so komplexe Probleme lösen – dann sicher auch die vergleichsweise einfachen Probleme anderer Unternehmen.
Facebook nutzt für die Entwicklung PHP. Kent Beck ist ein Software-Guru, Erfinder von eXtreme Programming, hat viel Zeit bei Facebook verbracht und begründet auf Quora die Wahl damit, dass PHP ein lokales Optimum darstellt. Facebook kontrolliert den kompletten Stack einschließlich aller Tools wie HHVM oder Hack und hat eine große PHP-Entwickler-Community. Mittlerweile hat das Unternehmen auch schon viel Geld in einen eigenen PHP-Stack investiert. Eine Migration würde viel Geld kosten – und das bei unklaren Vorteilen.
Aber Facebooks Wissen und Kontrolle über den PHP-Stack ist einmalig. Aus Facebooks Entscheidung kann man also nicht ableiten, dass PHP vor allem für große Codebasen sinnvoll ist.
Der Facebook-Code ist eine große monolithische Codebasis. Ein solches MonoRepo für allen Code hat zum Beispiel den Vorteil, dass ein Entwickler in einem Commit eine Bibliothek und alle abhängigen Projekte ändern kann. Dann müssen aber im Extremfall die gesamten 8 GByte Sourcecode erneut übersetzt werden. Dazu sind komplexe Optimierungen nötig.
Zweifellos lösen diese Ansätze die Herausforderungen bei Facebook. Andere Unternehmen sollten aber vorsichtig sein, diese Ideen einfach zu übertragen. Firmen wie Facebook haben eine unglaublich große Zahl an Entwicklern und Commits. Eine einzige große Codebasis, die jeden Tag zehntausende Commits hat, ist ungewöhnlich. So etwas ist nur ein Problem von Facebook oder anderen Firmen dieser Größenordnung. Gleichzeitig hat Facebook die Möglichkeit, hunderte Entwickler nur an Werkzeugen arbeiten zu lassen. Viele Projekte haben insgesamt nicht so viele Entwickler.
Also haben die meisten anderen Unternehmen weder die Möglichkeiten, solche Lösungen umzusetzen, noch die Probleme, die solche Lösungen erfordern.
Das gilt auch für die Technologien. Zwar bieten viele große Unternehmen wesentliche Teile ihrer Softwareinfrastruktur als Open-Source-Projekte an. Aber die Unternehmen haben direkten Zugriff auf deren Entwickler. Außerdem verdienen die Unternehmen nicht direkt mit den Projekten Geld. Sie haben oft kein so großes Interesse daran, die Nutzer der Projekte zufrieden zu stellen, wie Unternehmen, die von Open-Source-Projekten leben.
Große Unternehmen haben spezielle Probleme. Technologien oder Vorgehensweisen, die bei großen Unternehmen notwendig sind, müssen nicht unbedingt bei anderen Unternehmen vorteilhaft sein oder überhaupt funktionieren.
URL dieses Artikels:http://www.heise.de/-3767162
Copyright © 2017 Heise Medien
Fehler in Software müssen verhindert werden – dazu ist Software heutzutage zu wichtig. Also müssen Softwareteams testen. Aber reicht das aus?
Für ein Problem gibt es immer mehr als eine Lösung. Softwaretests verhindern, dass Fehler in der Software negative Auswirkungen haben. Tests verhindern keine Fehler: Sie finden Fehler, bevor sie zu Problemen führen.
Performancetests sind besonders schwierig: Das Benutzerverhalten muss simuliert werden, die zu erwartenden Benutzerzahlen müssen bekannt sein, und es muss ein Testsystem geben, das produktionsnahe Leistung erreichen kann. Diese Anforderungen sind oft unrealistisch. Bei neuen Features kann das Benutzerverhalten noch gar nicht bekannt sein. Ein System mit produktionsnaher Performance aufzubauen, ist oft zu teuer und zu aufwendig.
Wie kann ein Team ohne Tests Performanceproblem finden, bevor sie zu Problemen führen? Das Team kann eine neue Version nur auf einem Teil der Server deployen. Wenn es ein Performanceproblem gibt, können die Server mit der alten Version die Last abarbeiten. Die neue Version kann wieder aus der Produktion genommen werden – ohne dass es negative Auswirkungen gab. Dieses Vorgehen heißt Canary Releasing.
Für dieses Vorgehen muss das Monitoring passende Werte liefern, damit ein Problem frühzeitig erkannt wird. Ebenso müssen das Deployment und das Rollback automatisiert sein, um schnell und zuverlässig zu reagieren. Also lohnt sich neben Testen eine Investition in Monitoring und Deployment.
Bei Performance ist dieser Ansatz immer sinnvoll, weil Performancetests allein keine ausreichende Sicherheit bieten. Aber auch bei fachlichen Fehlern kann ein solches Vorgehen eine Ergänzung oder sogar der bessere Ansatz sein. Beispielsweise lassen sich alte und neue Version parallel betreiben. Die neue Version läuft "blind" – also ohne Auswirkungen auf die Daten –, und Ergebnisse werden verglichen.
Weitere mögliche Maßnahmen: Software kann öfter in Produktion gebracht werden. So erfolgen Änderungen in kleineren Schritten und damit mit geringerem Risiko. Das ist die Idee von Continuous Delivery. Oder die Software wird in mehrere unabhängig deploybare Module ("Microservices") aufgeteilt. Auch das verringert das Risiko eines Deployments, weil nur ein kleiner Teil des Systems betroffen ist.
Also sorgt erst eine Kombination von Tests und anderen Maßnahmen für qualitativ hochwertige Software.
Tests sind nur eine Möglichkeit, um Probleme mit Software zu verhindern. Es gilt, Handlungsalternativen zu kennen und die effektivste auszuwählen.
URL dieses Artikels:
http://www.heise.de/-3722870
Unternehmen wie Facebook leben von Software und entwickeln sehr große und komplexe Projekte. Wenn Vorgehen und Technologien so komplexe Probleme lösen – dann sicher auch die vergleichsweise einfachen Probleme anderer Unternehmen.
Facebook nutzt für die Entwicklung PHP. Kent Beck ist ein Software-Guru, Erfinder von eXtreme Programming, hat viel Zeit bei Facebook verbracht und begründet auf Quora die Wahl damit, dass PHP ein lokales Optimum darstellt. Facebook kontrolliert den kompletten Stack einschließlich aller Tools wie HHVM oder Hack und hat eine große PHP-Entwickler-Community. Mittlerweile hat das Unternehmen auch schon viel Geld in einen eigenen PHP-Stack investiert. Eine Migration würde viel Geld kosten – und das bei unklaren Vorteilen.
Aber Facebooks Wissen und Kontrolle über den PHP-Stack ist einmalig. Aus Facebooks Entscheidung kann man also nicht ableiten, dass PHP vor allem für große Codebasen sinnvoll ist.
Der Facebook-Code ist eine große monolithische Codebasis. Ein solches MonoRepo für allen Code hat zum Beispiel den Vorteil, dass ein Entwickler in einem Commit eine Bibliothek und alle abhängigen Projekte ändern kann. Dann müssen aber im Extremfall die gesamten 8 GByte Sourcecode erneut übersetzt werden. Dazu sind komplexe Optimierungen nötig.
Zweifellos lösen diese Ansätze die Herausforderungen bei Facebook. Andere Unternehmen sollten aber vorsichtig sein, diese Ideen einfach zu übertragen. Firmen wie Facebook haben eine unglaublich große Zahl an Entwicklern und Commits. Eine einzige große Codebasis, die jeden Tag zehntausende Commits hat, ist ungewöhnlich. So etwas ist nur ein Problem von Facebook oder anderen Firmen dieser Größenordnung. Gleichzeitig hat Facebook die Möglichkeit, hunderte Entwickler nur an Werkzeugen arbeiten zu lassen. Viele Projekte haben insgesamt nicht so viele Entwickler.
Also haben die meisten anderen Unternehmen weder die Möglichkeiten, solche Lösungen umzusetzen, noch die Probleme, die solche Lösungen erfordern.
Das gilt auch für die Technologien. Zwar bieten viele große Unternehmen wesentliche Teile ihrer Softwareinfrastruktur als Open-Source-Projekte an. Aber die Unternehmen haben direkten Zugriff auf deren Entwickler. Außerdem verdienen die Unternehmen nicht direkt mit den Projekten Geld. Sie haben oft kein so großes Interesse daran, die Nutzer der Projekte zufrieden zu stellen, wie Unternehmen, die von Open-Source-Projekten leben.
Große Unternehmen haben spezielle Probleme. Technologien oder Vorgehensweisen, die bei großen Unternehmen notwendig sind, müssen nicht unbedingt bei anderen Unternehmen vorteilhaft sein oder überhaupt funktionieren.
URL dieses Artikels:
http://www.heise.de/-3767162
Ein wesentliches Design-Prinzip unter Node.js ist es, den Code getreu dem Motto "small is beautiful" in möglichst kleine, wiederverwendbare Packages zu strukturieren. Bei komplexeren Projekten kann das jedoch schnell unübersichtlich werden, wenn für jedes Package ein eigenes Git-Repository zu verwalten ist. Das Tool "Lerna" verspricht Abhilfe.
Wer unter Node.js oder allgemein in JavaScript ein komplexes Projekt entwickelt und seinen Code getreu dem vorgenannten Motto in viele kleine Packages strukturiert, landet recht schnell bei 50, 100 oder noch mehr Packages. Verwaltet man jedes davon in einem eigenen Git-Repository, artet das schnell in viel Konfigurationsarbeit aus: sei es, um Abhängigkeiten untereinander zu verwalten, Build-Prozesse zu organisieren oder das Deployment zu npm zu steuern.
Aus diesen Gründen strukturieren Entwickler bekannter Frameworks wie Angular[1], React[2], Meteor[3] und Ember[4] oder bekannter Tools wie Babel[5] und Jest[6] ihren Code mittlerweile in sogenannten Monorepositories[7], kurz Monorepos oder auch Multi-Package-Repositories. Die Idee: Statt jedes Package in einem eigenen Git-Repository vorzuhalten, bündelt man zusammengehörige Packages in einem einzelnen Repository.
Die Vorteile liegen auf der Hand: Zum einen muss man sich nicht mit mehreren Git-Repositories "herumschlagen", zum anderen lässt sich der Build-Prozess für alle Module stark vereinfachen und, wie wir gleich sehen werden, auch das Deployment zur npm-Registry. Ein Tool, das hierbei hilft, ist Lerna[8].
Ursprünglich Teil von Babel[9], ist Lerna mittlerweile ein eigenständiges Node.js-Package und kann wie gewohnt über den Package Manager npm als globale Abhängigkeit installiert werden:
$ npm install -g lerna
Anschließend kann das Tool über den Befehl lerna aufgerufen werden, wobei eine Reihe verschiedener Parameter zur Verfügung stehen:
Ein Multi-Package-Repository definiert sich im Wesentlichen durch seine Struktur und über zwei globale Konfigurationsdateien: Zum einen über eine package.json-Datei, die Meta-Informationen für alle verwalteten Packages enthält, zum anderen über eine Konfigurationsdatei namens lerna.json, die wiederum Lerna-spezifische Meta-Informationen enthält. Die einzelnen Packages wiederum werden standardmäßig in einem Unterverzeichnis mit Namen packages einsortiert, sodass die Gesamtstruktur wie folgt aussieht:
multirepo/
node_modules/
packages/
package1/
node_modules/
src/
index.js
package.json
package2/
package3/
package4/
package5/
package6/
package.json
lerna.json
Diese Struktur kann man zwar manuell erzeugen. Alternativ steht aber auch wie oben schon erwähnt der Befehl lerna init zur Verfügung, der zumindest die beiden Konfigurationsdateien automatisch generiert:
$ git init multirepo
$ cd multirepo
$ lerna init
Dadurch wird zum einen das Modul Lerna als Abhängigkeit zu der package.json-Datei hinzugefügt (sofern dort noch nicht vorhanden) und zum anderen die Konfigurationsdatei lerna.json erzeugt. Zu Anfang sieht die Datei wie folgt aus und enthält die Versionsnummer der verwendeten Lerna-Bibliothek, eine Angabe darüber, unter welchem Verzeichnis die Packages liegen sowie eine Versionsnummer, die global für alle Packages gilt. Welche weiteren Konfigurationsmöglichkeiten es hier gibt, entnimmt man am besten der offiziellen Dokumentation[10].
{
"lerna": "2.0.0-beta.38",
"packages": [
"packages/*"
],
"version": "0.0.0"
}Die Struktur der einzelnen Packages in einem Multi-Package-Repositories unterscheidet sich nicht von einem Package, das als Single-Package-Repository verwaltet wird. Das heißt beispielsweise, dass jedes Package weiterhin über seine eigene package.json-Datei verfügt und darüber zum Beispiel auch seine eigenen Abhängigkeiten definiert.
Für Abhängigkeiten hingegen, die nur während der Entwicklung benötigt werden (Eintrag "devDependencies" in package.json) ist es in den meisten Fällen sinnvoll, diese in der globalen package.json eines Multi-Package-Repositories anzugeben.
Das hat mehrere Vorteile: zum einen ist auf diese Weise sichergestellt, dass alle Packages die gleiche Version einer verwendeten Abhängigkeit haben. Zum anderen reduzieren sich dadurch sowohl die Installationszeit als auch der verwendete Speicherplatz für die entsprechende Abhängigkeit, da sie – logisch – nur einmal für alle Packages (und nicht einmal für jedes Package) installiert wird.
Ein ebenfalls nützlicher Befehl ist lerna bootstrap. Dieser sorgt dafür, dass die Abhängigkeiten aller Packages installiert werden. Mit anderen Worten: Lerna ruft für jedes Package den Befehl npm install aus. Aber nicht nur das. Zusätzlich werden für alle Packages im Multi-Package-Repository, die als Abhängigkeit von einem anderen Package im Repository verwendet werden, symbolische Links erzeugt, was – Node.js-Entwickler werden das bestätigen – bei der Entwicklung enorm hilfreich ist. Zu guter Letzt wird dann noch für jedes Package der Befehl npm prepublish aufgerufen, wodurch die in den package.json-Dateien definierten "prepublish"-Skripte[11] ausgeführt werden.
Nimmt einem Lerna bis hierhin schon viel Arbeit ab, wird es bezüglich Deployment beziehungsweise Publishing noch besser. Der Befehl lerna publish sorgt dafür, dass die Versionsnummer für alle Packages, die sich seit dem letzten Release geändert haben, entsprechend hochgezählt wird. Dabei kann über einen kleinen Kommandozeilendialog ausgewählt werden, ob es sich um einen "Patch", einen "Minor Change", einen "Major Change" oder um einen "Custom Change" handelt (nett: Die jeweils neue Version wird in Klammern hinter der jeweiligen Auswahl angezeigt).
Aber nicht nur das: lerna publish sorgt weiterhin dafür, dass entsprechende Tags und Commits für die neue Version in Git erzeugt und alle Packages separat bei npm publiziert werden.
Die Bibliothek Lerna hilft bei komplexen JavaScript-Projekten, die aus mehreren zusammengehörigen Packages bestehen, den Überblick zu behalten: Sie erleichtert die Konfiguration des Build-Prozesses, die Verwaltung über Git und das Publishing zu der npm-Registry. Als Empfehlung sollte jeder Node.js-Entwickler, der mit komplexen Projekten oder einer komplexen Package-/Repository-Struktur zu "kämpfen" hat, bei Gelegenheit mal einen Blick riskieren. Eventuell lohnt sich ja der Umstieg.
URL dieses Artikels:
http://www.heise.de/-3718109
Links in diesem Artikel:
[1] https://github.com/angular/angular/tree/master/modules
[2] https://github.com/facebook/react/tree/master/packages
[3] https://github.com/meteor/meteor/tree/devel/packages
[4] https://github.com/emberjs/ember.js/tree/master/packages
[5] https://github.com/babel/babel/tree/master/packages
[6] https://github.com/facebook/jest/tree/master/packages
[7] https://github.com/babel/babel/blob/master/doc/design/monorepo.md
[8] https://github.com/lerna/lerna
[9] https://babeljs.io/
[10] https://github.com/lerna/lerna/#lernajson
[11] https://docs.npmjs.com/misc/scripts
Fehler in Software müssen verhindert werden – dazu ist Software heutzutage zu wichtig. Also müssen Softwareteams testen. Aber reicht das aus?
Für ein Problem gibt es immer mehr als eine Lösung. Softwaretests verhindern, dass Fehler in der Software negative Auswirkungen haben. Tests verhindern keine Fehler: Sie finden Fehler, bevor sie zu Problemen führen.
Performancetests sind besonders schwierig: Das Benutzerverhalten muss simuliert werden, die zu erwartenden Benutzerzahlen müssen bekannt sein, und es muss ein Testsystem geben, das produktionsnahe Leistung erreichen kann. Diese Anforderungen sind oft unrealistisch. Bei neuen Features kann das Benutzerverhalten noch gar nicht bekannt sein. Ein System mit produktionsnaher Performance aufzubauen, ist oft zu teuer und zu aufwendig.
Wie kann ein Team ohne Tests Performanceproblem finden, bevor sie zu Problemen führen? Das Team kann eine neue Version nur auf einem Teil der Server deployen. Wenn es ein Performanceproblem gibt, können die Server mit der alten Version die Last abarbeiten. Die neue Version kann wieder aus der Produktion genommen werden – ohne dass es negative Auswirkungen gab. Dieses Vorgehen heißt Canary Releasing.
Für dieses Vorgehen muss das Monitoring passende Werte liefern, damit ein Problem frühzeitig erkannt wird. Ebenso müssen das Deployment und das Rollback automatisiert sein, um schnell und zuverlässig zu reagieren. Also lohnt sich neben Testen eine Investition in Monitoring und Deployment.
Bei Performance ist dieser Ansatz immer sinnvoll, weil Performancetests allein keine ausreichende Sicherheit bieten. Aber auch bei fachlichen Fehlern kann ein solches Vorgehen eine Ergänzung oder sogar der bessere Ansatz sein. Beispielsweise lassen sich alte und neue Version parallel betreiben. Die neue Version läuft "blind" – also ohne Auswirkungen auf die Daten –, und Ergebnisse werden verglichen.
Weitere mögliche Maßnahmen: Software kann öfter in Produktion gebracht werden. So erfolgen Änderungen in kleineren Schritten und damit mit geringerem Risiko. Das ist die Idee von Continuous Delivery. Oder die Software wird in mehrere unabhängig deploybare Module ("Microservices") aufgeteilt. Auch das verringert das Risiko eines Deployments, weil nur ein kleiner Teil des Systems betroffen ist.
Also sorgt erst eine Kombination von Tests und anderen Maßnahmen für qualitativ hochwertige Software.
Tests sind nur eine Möglichkeit, um Probleme mit Software zu verhindern. Es gilt, Handlungsalternativen zu kennen und die effektivste auszuwählen.
URL dieses Artikels:
http://www.heise.de/-3722870
Softwareentwicklung ist eine sehr wichtige Branche. Aber können wir die Welt verbessern? Und wenn ja, wie? Tatsächlich können wir einiges dazu beitragen!
Die Statistik[1] besagt, dass in der IT die Arbeitslosigkeit relativ gering ist. Oft ist das Gehalt auch sehr gut. Allerdings sind in unserer Branche einige Gruppen wie Frauen, Menschen mit Behinderung oder verschiedene ethnische Hintergründe unterrepräsentiert. Also haben nicht alle den gleichen Zugang zu einer solchen Karriere.
Aber es geht nicht nur darum: Teams mit einer höheren Diversifikation können Probleme besser lösen. Es gibt mehr Sichten auf das Problem, und so betrachtet das Team mehr Lösungswege. Die Software wird auf diese Weise vielseitiger, und das Team bringt Produkte hervor, die für breitere Schichten interessant sind oder Probleme lösen, die einer homogenen Gruppe gar nicht bewusst sind.
Genau da können wir alle unterstützen. Indem wir mehr und andere Leute an die Softwareentwicklung heranführen, profitieren wir auch selber. Man lernt viel darüber, wie man Wissen vermitteln kann. Man reflektiert das eigene Wissen. Und Fragen können einen dazu bringen, Dinge aus einer ganz anderen Perspektive zu sehen. Wissensvermittlung ist in unserem Beruf eine der wichtigsten Tätigkeiten. Und am Ende macht es auch Spaß, jemandem etwas beizubringen.
Es gibt viele Initiativen, die Treffen organisieren, in denen Menschen anderen Menschen etwas beibringen. Diese Initiativen gibt es in ganz Deutschland und mit unterschiedlichen Zielgruppen.
Schon Kindern kann man etwas über Programmieren beibringen. Einige Initiativen sind:
Wie schon erwähnt, sind viele Gruppen in unserer Branche unterrepräsentiert. Es gibt einige Initiativen, die sich zum Ziel gesetzt haben, das zu ändern:
Es gibt auch Initiativen, die sich ganz allgemein zum Ziel gesetzt haben, Wissen über Softwareentwicklung weiter zu verbreiten:
Jeder kann helfen. Es gibt verschiedene Möglichkeiten:
Tatsächlich gibt es einige, die durch solche Initiativen eine Karriere im Bereich Softwareentwicklung gestartet haben. Mitmachen und mithelfen lohnt sich also!
PS: Danke an meine innoQ-Kollegen Pedro LaFuente Blanco, Lucas Dohmen, Christoph Iserlohn, Christine Koppelt, Ute Mayer, Stefan Tilkov und Daniel Westheide für die Hinweise auf einigen der Initiativen. Ohne sie wäre der Beitrag vermutlich nur halb so lang.
PPS: Unter ewolff.github.io/bildungsinitiativen/[28] findet sich die Liste der Initiativen auch auf GitHub. Jeder kann unter github.com/ewolff/bildungsinitiativen/[29] den Quellcode der Website einsehen und selbst Änderungen als Pull Request einreichen – man kann sogar im Browser Ergänzungen vornehmen. Wenn also eine Initiative fehlt: Gerne dort eintragen – oder unter dem Artikel einen Kommentar hinterlassen.
Initiativen u.a. für Kinder und unterrepräsentierte Gruppen ermöglichen einen einfacheren Zugang zu einer Karriere in der Softwareentwicklung und stärken unsere Branche. Daher: Mitmachen und das Wissen um die Initiativen weiterverbreiten!
URL dieses Artikels:
http://www.heise.de/-3663044
Links in diesem Artikel:
[1] https://statistik.arbeitsagentur.de/Statischer-Content/Arbeitsmarktberichte/Akademiker/generische-Publikationen/Broschuere-Informatik-2015.pdf
[2] https://coderdojo.com/
[3] http://www.devoxx4kids.de/
[4] http://www.hacker-school.de/
[5] https://www.teckids.org/
[6] https://jugendhackt.org/
[7] https://calliope.cc/
[8] http://codeweek.eu/
[9] http://railsgirls.com/
[10] https://railsgirlssummerofcode.org/
[11] http://railsgirlsberlin.de/wall-of-fame/
[12] http://unicornsintech.com/
[13] http://refugeesonrails.org/de/
[14] https://djangogirls.org/
[15] http://www.clojurebridge.org/
[16] http://www.scalabridge.org/
[17] http://www.womenwhogo.org/
[18] https://www.informatica-feminale.de/
[19] http://codegirls.de/
[20] https://codebar.io/
[21] https://www.womenwhocode.com/
[22] https://nodeschool.io/
[23] http://hackerspaces.org/
[24] http://heartofcode.org/
[25] https://haeqs.xyz/
[26] http://www.opentechschool.org/
[27] https://www.freecodecamp.com/
[28] https://ewolff.github.io/bildungsinitiativen/
[29] https://github.com/ewolff/bildungsinitiativen/
[unable to retrieve full-text content]
[unable to retrieve full-text content]
[unable to retrieve full-text content]
Selbstbestimmte Teams sind produktiver, diese Erkenntnis ist alles – nur nicht neu.
Immer wieder beschäftige ich mich mit Ansätzen und Organisationsformen, um besser verstehen zu können, was uns eigentlich oft daran hindert, eine Veränderung (wie Agilität) erfolgreich und nachhaltig umzusetzen. Dabei bin über den sogenannten soziotechnischen Ansatz gestolpert, der bereits in den 50er-Jahren entwickelt wurde. Dieser gründet sich auf der Erkenntnis, dass soziotechnische Systeme vor allem deswegen langfristiger und nachhaltiger ausgerichtet sind, da sie die Organisation ganzheitlich betrachten, das heißt sowohl den menschlichen/sozialen Aspekt als auch den technischen/wirtschaftlichen.
Mittels unterschiedlicher Forschungen und empirischen Untersuchungen konnte man nachweisen, dass teilautonome, selbstbestimmte Arbeitsgruppen produktiver sind, wenn ihnen die Verantwortung für größere, zusammenhängende Aufgaben übertragen werden und sie diese dann selbstorganisierend bearbeiten können. Im Vergleich dazu schnitten die Gruppen schlechter ab, bei denen die Aufgaben erst in kleinere Funktionen untergliedert und diese dann an einzelne Mitarbeiter übergeben wurden, die dann auch lediglich für diesen Funktionsteil zuständig waren (Stichwort: Taylorismus). Weiterhin wurde erkannt, dass bei den teilautonomen und selbstbestimmt arbeitenden Gruppen eher Generalisten benötigt werden, die sich gegenseitig vertreten können.
Diese gegenseitige Vertretung trug dazu bei, dass alle voneinander lernen konnten, wodurch sich auch nachweislich die intrinsische Motivation erhöhte. Außerdem wurden diese Gruppen dadurch in die Lage versetzt, ständig (kleine) Verbesserungen bezüglich der Umsetzung der Aufgaben vorzunehmen. Der organisatorische Nutzen davon war (neben der eben angesprochenen höheren Motivation und größeren Zufriedenheit der Mitarbeiter) vor allem auch eine größere Flexibilität, Qualität, Innovationsfähigkeit und eben auch Produktivität.
Dies wurde, wie gesagt, vor circa 70 Jahren erkannt. Zu dieser Zeit steckte die IT noch in den Kinderschuhen, vor allem aber die Softwareentwicklung in Teams. Und obwohl "wir" damals eine neue Disziplin begründeten und keine echten Altlasten hatten, waren wir dennoch der Ansicht, dass es sinnvoller wäre, tayloristisch vorzugehen. Das heißt, die Arbeit sollte funktional untergliedert und an einzelne Mitarbeiter übergeben werden, wie das unter anderem bei einem linearen Vorgehen zum Beispiel nach Wasserfall üblich ist. Das heißt, unser Verständnis, wie Arbeit zu bewältigen ist, basiert(e) auf Überlegungen aus dem Ende des vorletzten/Beginn des letzten Jahrhunderts.
Heutzutage, unter anderem mit dem Siegeszug der Agilität, fällt uns "plötzlich" ein, dass die Übergabe von größeren zusammenhängenden Aufgaben an selbstorganisierende Teams viel erfolgreicher sei. Ich frage mich, wieso haben wir 50 Jahre benötigt – das Agile Manifest ist ja mittlerweile auch schon 16 Jahre alt – bis wir das erkannt haben?
URL dieses Artikels:
http://www.heise.de/-3633011
Ständiges Lernen ist gerade in der IT-Branche wichtig. Ständig gibt es neue Technologien. Was sollen wir also lernen und anders machen? Sind Technologien wirklich entscheidend?
Die Arbeit in der IT-Branche ist auch deswegen interessant, weil es ständig etwas zu lernen gibt. Wir lernen viel von den großen der Branche – beispielsweise bei der Cloud von Amazon oder bei Microservices von Netflix. Aber setzten wir wirklich das Wichtigste um?
Die Amazon-Cloud und Microservices sind also technische Maßnahmen, um Selbstorganisation zu ermöglichen.
Viele Unternehmen nutzen Cloud und Microservices – aber nur als Technologie. So bringen die Ansätze nicht den vollen Nutzen. Schlimmer: Es werden die Auswirkungen moderner Organisation kopiert, die Organisation selbst wird aber nicht modernisiert. Das reduziert den Nutzen und wird die Adaption weiterer Technologien verkomplizieren.
Das Wissen darüber, wie erfolgreiche moderne Organisationen funktionieren, ist gut beschrieben. Eric Schmidt war lange CEO von Google und hat in seinem Buch "How Google Works" die wesentlichen Eckpunkte dargestellt. Es beschreibt Strategie, Kultur, aber auch den Einstellungsprozess. Ein wesentlicher Punkt: Manager ermöglichen und fördern Selbstorganisation.
Manchmal heißt es, dass diese Ansätze auf andere Unternehmen nicht passen, weil Google, Amazon oder Netflix ja Start-ups sind. Tatsächlich sind diese Unternehmen gemessen am Umsatz, an der Mitarbeiterzahl, am Gewinn und auch an ihrem Alter keine Start-ups mehr. Google beziehungsweise Alphabet ist nach Börsenkapitalisierung das zweitgrößte Unternehmen der Welt.
Außerdem konkurrieren diese Unternehmen mittlerweile mit klassischen Unternehmen. Im Bereich autonom fahrender Autos steht die klassische Autoindustrie beispielsweise mit Google im Wettbewerb. Also sollten auch wir Techniker mehr Wert auf den kulturellen Wandel legen – viel mehr als auf neue Technologien.
Nicht die neusten Technologien, sondern eine andere Organisation ist Kern erfolgreicher Unternehmen und von Microservices, Cloud usw. Die Organisation sollte kopiert werden – nicht nur die Technologien.
PS: Danke an den innoQ-Kollegen Michael Vitz für die Diskussion über eine frühe Version des Blog-Beitrags.
URL dieses Artikels:
https://www.heise.de/developer/artikel/Was-koennen-wir-von-Google-Amazon-und-Netflix-lernen-3634647.html
Links in diesem Artikel:
[1] https://www.heise.de/developer/artikel/Die-Cloud-Eine-Komponentenbibliothek-3354034.html
