Erfahrungen mit Pkw Solar-Lader?

Du meinst so, wie das "s" in "iot" für "secure" steht?

cu Michael

Ja, so in der Art.

Und beim neuen DevSecOps fehlt immer noch das 'QA'.

Gerrit

Sieghard Schicktanz, 2023-01-03 21:09:

Da hast Du wohl etwas falsch verstanden.

DevOp steht für "Development & Operations" und bezeichnet die engere Zusammenarbeit zwischen Entwicklung (Development) und Administration (Operations).

Wie kommst Du auf die Idee, dass das mit DevOp zu tun haben soll?

Das geht zurück auf Eric S. Raymond und seinen Text "Cathedral and the Bazaar", siehe auch:

Zitat:

"Release early. Release often. And listen to your customers."

Damit ist gemeint, dass man bei Software *häufiger* und mit *weniger* Änderungen neue Versionen bereitstellen soll, damit Kundenanforderungen frühzeitig berücksichtigt werden können und nicht erst nach 6 oder 12 Monaten Entwicklungszeit.

Nein, das meint diese Aussage eben *nicht*.

Gerrit Heitsch, 2023-01-04 06:49:

QA ist Teil der Entwicklung. Und nein "Development" meint *nicht* "Entwickler" sondern die gesamte Abteilung, die sich um die Entwicklung der Software kümmert - und ja, QA ist da auch ein Teil davon.

Gerrit Heitsch, 2023-01-04 17:11:

Nein, das ist in Dev enthalten. Offenbar habt ihr von Testverfahren keinerlei Ahnung.

Am 05.01.23 um 15:26 schrieb Arno Welzel:

Ich will ja gar nicht ausschließen, daß es irgendwo Universalgenies gibt, die das stemmen können, aber in der mir bekannten Praxis sieht das so aus, daß ich (unter anderem) seit knapp 30 Jahren Mailserver administriere und das Wissen über email in der Entwicklung sich darauf beschränkt, daß das Daten sind, die man dem Smarthost übergibt. Kein Wissen über rDNS, SPF, DKIM, inhaltliche Erwägungen, Bouncemanagement, oder gar mögliche Fehlerzustände im realen Internet. Und wie will man testen, wenn man nicht weiß, was in der Praxis alles schief gehen kann?

Man kann sich natürlich auf den Standpunkt stellen, daß es nicht das Problem es Entwicklers ist, wenn Google die Mail nicht will, weil man technisch alles richtig gemacht hat. Stimmt sogar irgendwo, ist aber dem Geschäftsziel dennoch nicht dienlich.

Peinlich wird es dann, wenn man nicht mal merkt, daß die Mails nicht ankommen, weil man die Bounces nicht will. "Wie, Mail empfangen, es stand nur senden im Pflichtenheft."

Lösung scheint es derzeit zu sein, email-Dienstleister als "Smarthost" zu nehmen. Davon alleine funktioniert es zwar auch nicht besser, aber dann existiert zumindest wieder eine unabhängige Instanz, die Feedback geben kann, was da für Grütze angeliefert wird etc. Eine unabhängige in-house QA hätte es natürlich genauso, und vermutlich billiger und schneller, getan.

Hanno

Hanno Foest, 2023-01-05 16:05:

Dazu braucht man keine "Universalgenies". Es genügt, wenn die Entwicklungsabteilung auch eine Qualitätssicherung hat. Und ja - das sind *verschiedene* Personen.

Bei einem meiner Arbeitgeber bestand die *Entwickungsabteilung* (Dev) aus 35 Entwicklern und 15 Leuten für Tests und Qualitätssicherung.

Ja, was sollte der die Entwicklung auch mehr wissen, wenn die Anwendung sich darauf beschränkt E-Mail zu senden. Die E-Mail muss formal korrekt sein - was danach passiert, ist nicht mehr Sache der Anwendung.

Eine Anwendung kann exakt *nichts* daran ändern, wenn ein fehlkonfigurierter Smarthost eine formal korrek eingelieferte Mail nicht los wird. Ob rDNS, SPF und DKIM korrekt konfiguriert sind, ist das Problem von Ops und nicht Dev. Und GMail ist *sehr* zickig bei der Annahme, weil dank Spammer so gut wie gar nichts mehr akzeptiert wird, was nicht von "vertrauenswürdigen" Quellen kommt. Wenn man über IPv4 einliefert, sind die Chancen höher - aber am Ende sucht man sich für Transactional Mail lieber gleich einen Dienstleister dafür.

Das ist nicht "peinlich" sondern da hat derjenige, der die Anforderungen aufgestellt hat, schlicht gepannt.

Doch, für Transactional Mail funktionieren Dienstleister wie Mailjet, Sendinblue etc. *viel* besser. Die verlangen nämlich Geld dafür und sind daher für Spammer komplett uninteressant. Deshalb ist die Zustellung darüber auch deutlich problemloser als über irgendwelche gemieteten Server bei Hostern, die GMail oder Microsoft als Spamschleuder einstuft.

Was auch immer Du damit sagen willst. Meine Erfahrung nach ist das Problem bei E-Mail *nicht*, dass Anwendungen etwas falsch machen, sondern dass beteiligte Server falsch konfiguriert sind.

Am 05.01.23 um 17:48 schrieb Arno Welzel:

Also alles das gleiche wie vorher, bloß mit formal anderen Abteilungsgrenzen? Super. :)

An der formalen Korrektheit hapert es halt.

Aber natürlich. Body nicht spammy aussehen lassen, auch extern existierende Absenderadressen benutzen, nicht immer wieder an den gleichen, nicht existierenden oder aus sonstwelchen Gründen Mail ablehnenden Empfänger schreiben... (weil man kein Bouncemanagement hat, oder es wegen mangelhafter Tests nicht funktioniert).

Eine schöne Theorie eines Theoretikers :)

In der Praxis benutzt dann Dev den falschen Absender und/oder falschen Smarthost, die Mail geht über den falschen Host raus und nichts paßt. Und beim "Testen" ging alles, weil die Testmails intern geroutet wurden. "Wie, da ist ein Unterschied?"

Funktioniert alles recht gut, sogar über IPv6. Zugegeben, ist nicht immer einfach, aber Freenet und GMX haben das letzte Jahr über mehr Probleme gemacht (ok, mag an der Kundenstruktur liegen).

Klar - derjenige, der die Anforderungen aufstellt, weiß besser, wie email funktioniert, als die Entwickler. :)

grep sendinblue client_access # sendinblue.com

Mailjet verschickte in den letzten Wochen auch ein paar Mal Spam, aber da war ich mal nicht so, da die zumindest antworteten und den Eindruck machten, was zu tun.

Ranzkisten bei Hetzner, mit IPs, über die mglw. schon ein Dutzend Leute drübergerutscht sind, sind ja auch eher die Spielzeugliga. Wo sollte der Spam herkommen, wenn man seinen eigenen Adreßbereich hat, für den man selber verantwortlich ist?

Andererseits hats Hetzner bei mir noch nicht in die Blockliste geschafft. Waren jetzt aber aufgrund ihrer inkompetenten Abuse-Abteilung ein paar Mal kurz davor. Wegen sowas:

"Thank you for your abuse report.

We can only process your report by first forwarding them to our customer. We cannot skip over this step. Your complaint cannot continue forward unless it is first sent to the customer."

Ja, ihr mich auch.

Das kann schon sein, daß es dir an Erfahrung mangelt, ja.

Hanno

Hallo Arno,

Du schriebst am Thu, 5 Jan 2023 15:25:26 +0100:

Wenn, dann allerdings zumindest nicht nur ich.

Ja, meist in der Form, daß die "Administration" die Ergebnisse der "Entwicklung" schon in frühen Stadien in die Hände bekommt und dann damit die Kunden "beglücken" kann.

Weil' s in dem Zusammenhang praktisch immer erwähnt wird, wenn man was darüber hört oder liest. Und erwähnt wird als eine grundlegende Vorgehensweise dabei.

Mag sein. Ob das eine gute Idee war?

Leider wird der _zweite_ Satz, wenigstens im kommerziellen Umfeld, meistens nicht zitiert und ist deshalb dort wohl weniger bekannt.

Und damit implizierst Du, daß die (so) entwickelte Software schon _vor_ der wirklichen Fertigstellung (nach 6 oder 12 Monaten Entwicklungszeit) dem Kunden zur Nutzung vorge, äh, legt werden soll, und erst später die Funktion mit "*häufige[n]* und mit [jeweils] *wenige[n]*" Änderungen allmählich zur vollen Funktion gebracht werden soll.

Wie sonst könnte Deine vorstehende Einlassung realisiert werden?

(Kennst Du die "Einführungsphase" der ersten "Model 3" von Tesla? Die haben das angeblich nach diesem Konzept durchgezogen.)

Hanno Foest, 2023-01-05 18:41:

Der Unterschied ist, dass bei der Zusammenfassung von "Entwicklern" und "Qualitätssicherern" in einer Abteilung auch eher zusammengearbeitet wird. Die QA bekommt das Produkt nicht erst nach Monaten vorgelegt, wenn es eigentlich schon fertig sein soll, sondern auch auf dem Weg dorthin, z.B. alle 2-4 Wochen, um zu prüfen, ob die bisherigen Änderungen Probleme verursachen.

Die formalen Korrektheit einer E-Mail hat aber nichts damit zu tun, ob man weiß, wie man rDNS, SPF oder DKIM konfiguriert.

Für die Auswahl der richtigen Absenderadresse ist aber nicht die Anwendung zuständig sondern die Person, die die Adresse festlegt. Und auch "spammy" muss formal definierbar sein und nicht nur ein subjektives Gefühl eines Mailserver-Admins - z.B. Test des Inhalts gegen existierende Spamfilter.

Das Problem "Mail an ablehnenden Empfänger schreiben" zu lösen hat mit der technischen Korrektheit Anwendung auch erstmal nichts zu tun. Die Empfängeradresse muss auch jemand festlegen - aber das hat nichts damit zu tun, ob die Anwendung technisch korrekt arbeitet.

Nein, Praxis. Wieso sollte die Entwicklung sich um die Nameserver und Funktion des Mailservers, der die Header für DKIM signiert, kümmern?

In der Praxis hat der Dev nicht selbst zu entscheiden, welchen Smarthost er wofür benutzt, sondern sich daran zu halten, was man ihm vorgibt.

Ja, derjenige, der die Anforderungen stellt, weiß besser, wie *er* E-Mail in der Anwendung nutzen will.

Und ja, es kann auch die Anforderung geben, dass eine Anwendung E-Mail versenden soll *ohne* Prüfung, ob ein Bounce ausgelöst wurde, weil der die Prüfung auf Bounces woanders passiert und ganz bewusst nicht in der Anwendung. Die Welt ist nicht immer so schön schwarz/weiß wie man sie sich manchmal vorstellt.

Wer etwas konkretes haben will, muss es auch so beschreiben. Deswegen gibt es ja auch noch Softwarearchitekten und Produktmanager, die solche Aspekte im Zweifelsfall hinterfragen - und ja, die sollten von der Materie dann natürlich auch Ahnung haben.

Ja, sicher. Nur weil bei Dir so eine Regel existiert, bedeutet nicht, dass das bei Anderen auch so ist.

Möglich. Ich mache das erst seit etwa 20 Jahren.

Sieghard Schicktanz, 2023-01-05 21:44:

Nein, damit meine ich, dass man *neue* Funktionen nicht erst nach einem Jahr kommen, sondern dann, wenn sie fertig und getestet sind.

Dass man Software generell schon anbieten soll, obwohl sie nicht benutzbar ist, habe ich nicht behauptet.

Dass man nicht erst eine Liste von 100 Änderungswünschen sammelt und dann 1-2 Jahre entwickelt, sondern dafür sorgt, dass das Projekt idealerweise nach *jeder* für sich unabhängig nutzbaren Änderung stabil und auslieferbar ist.

Was die Firmen von Musk angeblich irgendwie gemacht haben sollen, ist mir herzlich egal. Weiterhin gab es bei Tesla keine Kunden, die ein Fahrzeug mit konkreten Anforderungen beauftragt haben, die Tesla dann so umgesetzt hat, sondern nur Herrn Musk, der mit dem Ding Geld verdienen wollte.

Am 06.01.23 um 03:25 schrieb Arno Welzel:

Steht da ja auch nicht.

Das ist nicht eine Adresse, sondern verschiedene, und bestimmt werden die von der businesslogic. Rat mal, wer die schreibt...

Klar ist das definierbar. Allerdings müßte erst mal jemand auf die Idee kommen, daß das eine Rolle spielt und danach fragen. Probleme, die man kennt, kann man angehen. Probleme, die man nicht kennt, werden nicht angegangen.

Natürlich kann man völlig korrekt arbeitende email-Anwendungen schreiben, die wegen wiederholten Versands an ablehnende Empfänger-Adressen den Absender auf die Shitlist bringen. Ist dem Geschäftsziel trotzdem nicht dienlich, und ich vermochte durchaus zu kommunizieren, daß technische Korrektheit im Detail ohne Blick auf das große Ganze nicht ausreicht.

Weil die Entwicklung überhaupt erst mal wissen muß, warum bzw. daß es nicht gut ist, wenn man über den falschen Mailserver raussendet. Ohne Verständnis der Zusammenhänge ist ihr das nämlich egal, und es geschieht das zu Beobachtende.

Diese deine Haltung "ich bin ein Fachidiot, ich muß nichts von den Zusammenhängen verstehen und mich um nicht kümmern, ich bin einfach nur codemonkey meinem Kämmerlein und guck nicht über den Tellerrand" ist genau das Problem.

In der Praxis codet der Dev die Businesslogic, die je nach Geschäftsprozess unterschiedliche Absenderadressen benutzt. Guten Morgen.

Da, wo Manna vom Himmel fällt, vielleicht. Derjenige, der die Anforderungen stellt, möchte typischerweise, daß sich emails in der Inbox des Kunden manifestieren, Details sind egal und könnten auch als Magie beschreiben werden.

Wenn es gut "agil" läuft, vermögen ihm die Techniker Details zu erklären, wie daß es nicht gut ist, Karteileichen bzw. gelöschte Empfängeradressen nicht auszusortieren, so daß sie immer wieder im Rahmen von Newslettern angeschrieben werden, während ihre Zahl steigt. Dann kann man das Konzept interaktiv oder iterativ anpassen. Aber halt nur, wenn die Techniker um die Probleme wissen und entsprechend Feedback geben können.

Ist mir völlig egal, wie andere das handhaben und ob die ihren Spam artig aufessen. Jedenfalls zeigt mir der ankommende Spam von Mailjet, Sendinblue etc. daß "für Spammer komplett uninteressant" irgendwie anders aussieht.

Man kann auch seit 20 Jahren stümpern.

Hanno

- To make error is human. To propagate error to all server in automatic way is #devops.

Hm - die hab' ich noch nicht geblockt (in der Firma hatte ich aber schon mehrfach Spam von denen).

GMail (100% Spam, 5-10 am Tag), sendgrid, AWS, Azure und Oracle Cloud sind bei mir aufgrund reichlich Spam komplett geblockt (mit der Option auf einzelne whitelist-Einträge bei Bedarf, was selten passiert).

cu Michael

Am 06.01.23 um 17:06 schrieb Michael Schwingen:

Ist bei mir ähnlich. Sehr übel sind auch OVH, Digitalocean, Quadranet. Von denen sehe ich nur noch Spam, wenn die ein neues Netz haben, das aber dann sehr zeitnah. Go figure.

GMail kann ich leider nicht blocken, weder privat noch geschäftlich - Erpressung mittels Kundenmasse.

Hanno

Da habe ich zum Glück nur ganz wenige Kontakte - im Moment habe ich da IIRC genau einen whitelist-Eintrag definiert für einen Kollegen, der aber auch noch eine Alternativ-Adresse hätte.

cu Michael

Hallo Arno,

Du schriebst am Fri, 6 Jan 2023 03:38:14 +0100:

Du nicht...

...

Was für die "anderen" Kunden halt bedeutet, daß sie _schon wieder_ eine neue Version kriegen, installieren _und testen_ müssen. Wenn die läuft, ist das nur ärgerlich, wenn die dann einen (vielleicht schon lange bestehenden) Fehler finden - was meinst Du, was die dann sagen?

Es ging um eine bestimmte Firma und unabhängig vom 2CEO2.

Leider machen das _viele_ (Software-) Firmen ähnlich, und die Autohersteller sind die, die das am lautesten propagieren, obwohl gerade die solche Vorgehensweisen besonders kritisch betrachten sollten und im Zweifelsfall eine Entwicklung lieber etwas verzögern als ein unsicheres Ergebnis ausliefern.

Hanno Foest, 2023-01-06 04:20:

Nein, aber in snipped-for-privacy@mid.individual.net>, Zitat:

"Kein Wissen über rDNS, SPF, DKIM, inhaltliche Erwägungen, Bouncemanagement, oder gar mögliche Fehlerzustände im realen Internet. Und wie will man testen, wenn man nicht weiß, was in der Praxis alles schief gehen kann?"

Das klang so, als erwartest Du, dass die Entwicklung sich bitte auch damit auseinanderzusetzen hat, weil sie sonst unfähig sind, Anwendungen zu erstellen, die E-Mails korrekt an einen Smarthost übergeben können.

Nochmal: *Technisch* ist es für die Anwendung völlig egal, welche Adressen benutzt werden. Das legt *nicht* die Entwicklung fest, die sich um die *technische* Umsetzung kümmert.

Korrekt - und auf diese Probleme muss jemand hinweisen und nicht stillschweigend erwarten, dass sie bekannt sind und sich dann darüber ereifern, dass die Entwicklung keine Ahnung hat. Genau deswegen gibt es ja "DevOps" - damit genau sowas passiert.

Korrekt - aber was genau hat nun die *Entwicklung* damit zu tun, das "große Ganze" zu sehen?

Es ist in erster Näherung erstmal überhaupt wichtig, keine Fehler zu machen. *Wenn* dann Fehler auftreten, *dann* muss man sich anschauen,

Wieso? Ich verstehe die Zusammenhänge doch. Aber ich mache den Job auch insgesamt schon über 30 Jahre in der Entwicklung und seit etwa Anfang der 2000er auch sehr ausgiebig immer wieder in der Administration. Dennoch erwarte ich nicht von einem jedem Entwickler unabhängig von seiner Erfahrung, dass er das selbe Wissen hat, wie ein Administrator mit langjähriger Praxis.

Absenderadressen sind aber nicht Teil der Businesslogic sondern eine organisatorische Festlegung. Eine Anwendung, wo die Absenderadresse im

Die E-Mail-Adresse für "Inbox des Kunden" *muss* aber jemand definieren.

Genau dafür ist DevOps da.

Da sowohl Mailjet wie auch Sendinblue für einen Account nur 200 Mails pro Tag erlauben, solange man nicht bezahlt, scheinen das dann wohl zahlende Kunden zu sein, die den Spam schicken - das wäre zumindest unerwartet.

Man kann auch sein Leben lang nicht dazulernen wollen und seine Vorurteile pflegen.

Michael Schwingen, 2023-01-06 17:06:

Solange man keine Endkunden hat, die einen über GMail erreichen wollen, kann man das natürlich so machen.

Hanno Foest, 2023-01-06 17:19:

Also eigentlich Alle, außer Firmen mit eigenen Mailservern.