วีดีโอ

Hallo Hans, Unseres Wissens nach gibt es die Seiten nicht auf Deutsch. Wenn es dir hilft, kannst du aber die Seite mittels Tools wie www.deepl.com/de/translator von Englisch auf Deutsch übersetzen lassen. Das sind Hendriks beide Seiten: - theBread.code(); www.the-bread-code.io/ - The Sourdough Framework: www.the-sourdough-framework.com/ Wir haben das Kommentar auch an Hendrik weitergeleitet.

Moin Hans! Leider aktuell nur auf Englisch 😞. Danke aber für das Interesse!

Hey Johnny, Volle Zustimmung. Es kommt wahrscheinlich (eigentlich wie immer) auf den Kontext des Codes an. Ich würde noch hinzufügen, die Variablen mit englischen Namen zu versehen, also aus deinem Beispiel eher in Richtung "row" und "column". Denn wir wissen nie, wer unseren Quellcode liest.

@_coderizon Freut uns! Das Lob geht voll uns ganz an Data Science Deep Dive. Deine Frage haben wir an das Team weitergeleitet.

Hallo @_coderizon, danke für dein Feedback und deine Frage. Leider lässt sich das pauschal nicht beantworten. Die Kosten hängen zum größten Teil von den Anforderungen deines Modells ab. Für einen lokalen Server ist eine GPU nötig. Die Einstiegsmodelle sind die sogenannten “Consumer GPUs”, die preislich aktuell bei etwa 2000 Euro liegen. Wir nutzen eine GPU, die etwas mehr Ressourcen mitbringt (NVIDIA L40S), die preislich aktuell im hohen 4-stelligen Bereich liegt. Die Stromkosten können je nach Anwendung ebenfalls ein Faktor sein, den es sich lohnt zu berücksichtigen. Alternativ kannst du eine VM in der Cloud nutzen, z.B. bei AWS oder Hetzner. Leider kann ich hier keine Links einfügen, da TH-cam dann meine Antwort löscht. Daher hier mal ein paar Hinweise auf Links: Übersicht über AWS Instanz-Typen unter aws.amazon.com/ec2/instance-types/ Das AWS pricing dazu unter aws.amazon.com/ec2/pricing/on-demand/ Ein weiteres Beispiel bei Hetzner: hetzner.com/dedicated-rootserver/matrix-gpu/ Huggingface beschreibt das Pricing hier sehr gut: huggingface.co/docs/inference-endpoints/pricing Auch wenn ich keine allgemeingültige Antwort geben kann, hoffe ich, dir weitergeholfen zu haben. Melde dich gern, solltest du noch weitere Fragen haben. Viele Grüße Michelle

@@mgolchert-inwt Danke <3

Oh. Danke. Dies wusste ich garnicht.

<3

Danke! Wir werden mal schauen was möglich ist. Einen Steuerberater zu finden, der sich in dem Feld auskennt wird nicht einfach sein,.

danke für den tipp @notsure228 - lg, Wolfi und Andy

Wow @g0mf! Danke, dass du dir für die Antwort Zeit genommen hast. Du hast natürlich Recht damit, dass nicht jede Clean Code Regel auf jeden Anwendungsfall passt. "Nutze das richtige Tool für das entsprechende Problem". Dennoch sind manche Regeln schon allgemein anwendbar. Die Pfadfinder-Regel zB. Hinterlasse den Code besser als du Ihn vorgefunden hast. Ein Kommentar bzw. eine sinnvolle Benennung von Variablennamen lässt sich überall anwenden. Aber ich bin da generell bei dir. Es sind halt Guidelines und ein Entwickler*in sollte sich bewusst sein, wann es OK ist, diese nicht zu befolgen. Bei dem Punkt der Performance/Resourcen-Verbrauch sehe ich das ganze etwas anders. Ich bin bei dir, dass man sich darüber Gedanken machen sollte. Was ich aber nicht denke ist, dass jeder einen Profiler oder Tracer bedienen können muss. Das hebt die Barriere fürs Programmieren schon sehr an. Speziell in Bereichen, wie JavaScript, wo viele Bootcamps versuchen, die Hürde gering zu halten. Es ist aber auch was anderes, WO der Code ausgeführt wird. Die meisten JS-Libs werden im Browser, also auf dem Clienten ausgeführt. Der Resourcen-Verbrauch wird hier pro User also nicht addiert/multipliziert sondern eher gesharded. Bei Server-Apps ist das i.d.R. genau anders. Da sehe ich es kritischer an, weil mehr User oft zu mehr Resourcen-Verbrauch führen. ich sage nicht, dass der Resourcen-Verbrauch egal ist. Ich sage nur, dass der Kontext eine große Rolle in der Priorisierung der ganzen Sache spielt. Wir sollten die Compute-Resourcen so gering wie möglich halten, auch schon der Umwelt zu liebe.

@@engineeringkiosk Du hast absolut recht. Wenn man anfängt programmieren zu lernen, dann ist Performance erst einmal zweitrangig. Ich würde das gleiche auch für Hobby-Projekte oder Prototypen sagen. Wenn man jedoch ein professioneller Softwareentwickler ist, der für seine Arbeit bezahlt wird, und dessen Produkte für Geld an Kunden verkauft werden, dann muss man Profiler/Tracer bedienen können. Ich weiß das mögen manche Leute nicht hören, was verschiedene Gründe haben kann, aber mir geht es bei dem Punkt ganz klar um die Interessen der Kunden. Zu der Frage "wo" der Code ausgeführt wird, möchte ich eine Sache anmerken: Das eigene Programm läuft natürlich nicht im Vakuum, sondern neben vielen anderen Programmen auf dem System des Users. Wenn jedes Programm "schlampig" mit den Resourcen umgeht, addiert sich die "Schlampigkeit" auf. Es ist dann nicht mehr ein Bottleneck, sondern eine höhere Grundlast, die entsteht. Und es sind nicht nur die Kunden, die unter schlechter Performance leiden, sondern auch die QA, Tester, Designer und Entwicklerinnen im eigenen Unternehmen. Ich bin voll bei dir, dass der Kontext eine große Rolle bei der Priorisierung spielt. Mein Anspruch an Softwarequalität ist an der Stelle einfach höher, was Stabilität und Performance angeht. Das steht oft im Widerspruch zu dem, wie manche Unternehmen ihre Produkte entwickeln. Vielleicht könnte der Umweltaspekt, den du ansprichst, diese Unternehmen zum Umdenken anregen. Genau wie Robert C. Martin die Messlatte höher gesetzt hat, was akzeptable Code-Qualität angeht, so setzt Casey Muratori die Messlatte höher, was akzeptable Performance angeht. Auch wenn man sie nicht erreicht, muss man zumindest versuchen sich zu verbessern, sonst degradiert unsere Industrie.

Denken wir auch. Die Diskussion selbst ging ja noch recht lang auf GitHub weiter: - Teil 1: github.com/cmuratori/misc/blob/main/cleancodeqa.md - Teil 2: github.com/cmuratori/misc/blob/main/cleancodeqa-2.md Ist zwar ein sehr langer "read", aber doch schon sehr interessant. Auch wie beide sich in manchen Punkten Stück für Stück annähern. (~Andy)

jup, wenn man nicht direkt vor seinen podcast mics sitzt ist der ton gleich eine höhere herausforderung. aber wir werden das weiter versuchen zu verbessern.

hast du was dagegen? ;)

danke dir!