Ja, ich denke auch, dass man diese Fähigkeit kontinuierlich weiter erforschen und ausbauen muss.

Vielen Dank für diesen wirklich guten Kommentar :)

Bitte senken Sie die Gebühren ..

Übersetzung: https://rosettalens.com/s/ko/introducing-pay-per-crawl

Das wird zwar auch im Artikel erwähnt, aber ich habe zusätzlich einen eigenen SP-Simulator gebaut, der auf Basis der Workloads der letzten n Tage berechnet, wie viel SP man noch zusätzlich kaufen sollte, damit „bestehende Kosten + durch Coverage reduzierte Kosten + durch Recurring verschwendete Kosten“ insgesamt am geringsten ausfallen, und auf dieser Grundlage habe ich dann Entscheidungen getroffen.

Stimmt schon....

Ich war auch neugierig und teile hier, was ich Claude dazu gefragt habe ... aber so richtig nachvollziehen kann ich es nicht.

Ich werde die Vor- und Nachteile der Verwendung von TypeScript kritisch analysieren:

Vorteile (Pros):

1. Integration ins Entwicklungsökosystem

• Die meisten Beispiele konzentrieren sich auf Web-Frameworks (React, Vue, Svelte usw.)
• Die Einstiegshürde für Frontend-Entwickler wird minimiert
• Das npm-Ökosystem kann genutzt werden

2. Technische Vorteile

• Typsicherheit verhindert Konfigurationsfehler in der Infrastruktur im Vorfeld
• Native ESM-Unterstützung modernisiert das Modulsystem
• Natürliche Unterstützung für asynchrone Verarbeitung (async/await)

3. Erweiterbarkeit

• Das Merkmal "Extensible" wird betont – funktionsbasierte Ressourcenerweiterungen sind leicht umzusetzen
• Einfache Integration von AI ("AI-first" wird betont)
• Unterstützung für verschiedene Laufzeitumgebungen, vom Browser bis zu Serverless

Nachteile (Cons):

1. Leistungsbedenken

• TypeScript erfordert einen Kompilierungsprozess
• Der Speicherverbrauch ist höher als bei Systemsprachen wie Go oder Rust
• Bei der Verwaltung großer Infrastrukturen sind Performance-Engpässe möglich

2. Sicherheitsrisiken

• Aufgrund der dynamischen Eigenschaften von JavaScript/TypeScript sind Laufzeitfehler möglich
• Zugriff auf riskante Funktionen wie eval() ist möglich
• Komplexität des Abhängigkeitsmanagements (auch wenn "zero dependencies" behauptet wird, ist es in der Praxis sehr wahrscheinlich, dass zusätzliche Abhängigkeiten hinzukommen)

3. Technische Grenzen

• Eingeschränkter Zugriff auf Low-Level-Systeme
• Unvorhersehbare Verzögerungen durch Garbage Collection
• Schwierigkeiten bei der Erstellung nativer Binärdateien

4. Bedenken zum Ökosystem

• Als IaC-Tool ist es noch relativ unreif
• Im Vergleich zu Terraform und Pulumi ist die Community bzw. das Ökosystem kleiner
• Es fehlt an Enterprise-tauglicher Unterstützung bzw. Validierung

5. Architekturbezogene Überlegungen

• "No strong opinions" kann im Gegenteil auch ein Nachteil sein (fehlende Best Practices)
• Risiko einer verteilten Zustandsverwaltung ("store state anywhere")
• Die Verwaltung lokaler State-Dateien ist komplex

Zusammenfassend lässt sich sagen, dass die Wahl von TypeScript gut geeignet ist, um eine webentwicklerfreundliche Umgebung aufzubauen, als IaC-Tool auf Enterprise-Niveau aber noch weiter validiert werden muss.

Ich arbeite derzeit bei AWS Korea.

Eine der wichtigsten Schulungen, von denen man nach dem Eintritt hört, ist, darüber nachzudenken, wie Kunden ihre Cloud-Kosten senken können; als eine der effektivsten Methoden werden dabei RI & SP empfohlen.

RI vielleicht nicht, aber im Fall von SP kann es auf mehrere Workloads angewendet werden, sodass es sich definitiv lohnt, darüber nachzudenken, wenn es fixe laufende Kosten gibt. Wir haben sie sogar unter Berücksichtigung des erwarteten Optimierungszeitpunkts gekauft ... haha. Wenn wir zum Beispiel davon ausgegangen sind, dass die Optimierung in 9 Monaten abgeschlossen sein und sich die Serverkosten halbieren würden, war es trotzdem vorteilhafter, gleich für ein ganzes Jahr zu kaufen, also haben wir es auch so gemacht.

Unabhängig davon, ob es KI ist oder nicht: Wenn Crawling gezielt betrieben wird, lässt es sich ohnehin nicht erkennen.

Woran wird unterschieden, ob es ein KI-Bot ist oder nicht?

Eine Kombination, an die ich überhaupt nicht gedacht hätte — überraschend. Ich frage mich, was Grammarly damit vorhat.

Warum wurde unbedingt TypeScript verwendet, ...

Cloudflare will damit Geld verdienen.
Letztlich werden sich alle, die Geld verdienen wollen, dort sammeln.
Das Volumen von Cloudflare wird wachsen.
Und die Daten werden qualitativ schlechter werden.
Dasselbe Muster war auch bei Naver, Instagram und YouTube zu sehen – überall dort, wo Geld im Spiel ist.

Oho … Wenn man zumindest die grundlegendsten Tags setzt, kommt man wohl schon ein gutes Stück weiter … :)

Aber ist es eigentlich Standard, die Kosten auch mit Dingen wie RI oder SP zu senken …? Es ist auf jeden Fall ein Punkt, über den man viel nachdenken muss: welche Größen wir in unserer Infrastruktur tatsächlich nutzen werden …

Bitte macht auch eine Windows-Version, bitte ;_;

Gridfinity ist eine der Formen, die man zu Beginn beim 3D-Druck besonders häufig ausprobiert.
Es ist nützlich, wenn man etwas in Schubladen organisieren oder Aufbewahrungsbehälter für den Schreibtisch drucken möchte.

https://www.printables.com/search/models?ctx=models&q=gridfinity
https://makerworld.com/en/search/models?keyword=gridfinity

Schon allein bei einer Suche nach Gridfinity findet man viele unterschiedliche Anwendungsbeispiele.

Ich persönlich drucke und nutze für Schubladen die BaBo-Serie.
https://makerworld.com/en/models/14125-babo-organizer-drawer-module-30

Auch BaBo + Gridfinity ist möglich.
https://printables.com/model/…

Hm … warum habe ich das so geschrieben? schluchz Es scheint, dass „als Code“ passender wäre.

Wenn eine einzelne Zeile lang ist, ist das schon möglich.
Mit der Google-Suchmaschine wäre es wahrscheinlich auch möglich, wenn man lang genug schreibt, lol

Woher kommt wohl die Redewendung „mit nur einer Zeile Code …“?

Es ist eine Ehre, dass es auch in Korea solche YouTube-Videos gibt. Ich werde sie als gute Referenz nutzen, vielen Dank!