Java Web Weekly, Ausgabe 114

Gleich zu Beginn des letzten Jahres habe ich mich entschlossen, meine Lesegewohnheiten zu verfolgen und ** das Beste zu teilen. Haven hat keine Bewertung verpasst.

  • Auf geht’s…​**

1. Frühling und Java

>> Schreiben von Unit-Tests mit Spock Framework: Einführung in Spezifikationen, Teil drei [t]

Dieser Artikel beschäftigt sich mit dem Testen mit Spock , diesmal mit einem genauen Blick auf die Spezifikationen.

Ein kurzes Update zu den Ereignissen von Unsafe in Java 9 .

>> Support Java 6, 8, 9 in einer einzigen API []

Sehr interessanter Ansatz zur Unterstützung mehrerer Java-Versionen in einer öffentlichen API . Wenn Sie eine öffentliche API erstellen oder verwalten, lohnt es sich auf jeden Fall.

Und als Randbemerkung - wenn Sie sich für Marketing interessieren, ist dies eine gute Idee, wie Sie Inhalte produzieren, die Ihr Produkt unterstützen.

> > So kombinieren Sie den dem Ruhezustand zugewiesenen Generator mit einer Sequenz oder einer Identitätsspalte []
  • Die Identität einer Entität ** ist sehr viel komplexer, als nur ein @ Id zu schlagen und es täglich zu nennen.

Auch lesenswert:

Webinare und Präsentationen:

Zeit zum Upgrade:

2. Technisch

>> Sensible Mutationstests: Fahren Sie nicht fort ein tödlicher Spree []

Mutationstests machen die falsche Metrik, die die Codeabdeckung darstellt , etwas weniger als betrügerisch. Es scheint leicht genug einzurichten, also versuche ich es definitiv.

>> Wie schreibe ich Golden Master Tests nicht? []

Wie immer ein tiefes Eintauchen in die Feinheiten, ein bewährtes, einfach zu wechselndes System zu erhalten.

Ein interessanter und auf jeden Fall hilfreicher Blick auf die Funktionsweise von DDoS-Angriffen, auf die Auswahl von Zielen und auf die möglichen Maßnahmen.

Hinweis: Eine gute Protokollierung kann das Muster frühzeitig erkennen. Reagiere darauf - na gut, das ist nicht so einfach wie das Wissen, dass es passiert.

>> Sollen wir einen Codierungsstandard verwenden? []

Ich war an meinem fairen Anteil an Kodierungsstandarddiskussionen (nennen wir sie "Diskussionen"), bei denen ich jemanden von etwas überzeugen wollte.

Es macht nie Spaß und ist fast immer unproduktiv - daher neige ich dazu, dieses Problem jetzt anders anzugehen (Hinweis - ich bin viel flexibler als in meinen frühen Tagen).

Dieses Schreiben geht über einen Teil dieses Prozesses und macht einige wirklich gute Punkte, die Sie aufheben und verwenden können , wenn Ihr Team den Abzug bei einem Codierungsstandard betätigt.

Auch lesenswert:

3. Überlegungen

>> Der majestätische Monolith []

Monolithen haben einen schlechten Ruf. Es ist wirklich wichtig zu wissen, wo Monolith sinnvoll ist und welche Art von System wirklich eine Microservice-Architektur benötigt.

Diese frühe Entscheidung hat das klare Potenzial, Ihnen viele Monate zusätzliche Entwicklungsarbeit zu ersparen, um dorthin zu gelangen, wo Sie sein müssen.

>> Voraussetzungen für eine effektive Überprüfung des Codes []

Versuche, Code zu überprüfen, sind Legion. Positive, nützliche und lernorientierte Code-Review-Kulturen gibt es nur wenige.

Und das ist definitiv so, weil die Praxis einige Dinge erfordert, um gut zu funktionieren - nicht zuletzt das gewisse Maß an emotionaler Reife.

>> Ich habe meine Wette verloren: Der PC ist nicht tot …​ noch []

Ein paar Spaß lesen, wie schnell die allgemeine Tech-Industrie voranschreitet.

>> So stellen Sie Software bereit []

Dies ist kein Beitrag, es ist ein kleines Buch

Es ist auch eine intelligente, klar geschriebene Beschreibung darüber, was nötig ist, um Ihre Arbeit dort hin zu bringen und sie gut zu machen.

Es lohnt sich, es zu lesen, wenn Sie nur den "Einsatzstress" (echte Erkrankung) und den zehnfachen Chill-Faktor bei der Produktion beseitigen möchten.

>> InfrastructureAsCode []

Eine bekannte Praxis in der DevOps-Welt und hoffentlich auch außerhalb davon.

Ich erwarte, dass dieser Artikel wie die vorige Serie weiter wächst, nach dem sehr interessanten Konzept der Evolving Publication.

Auch lesenswert: