- Replit – Build apps and sites with AI
- Replit is an AI-powered platform for building professional web apps and websites.
Replit Jahresabonnement
Ich habe mich am 1.12. aufgrund des Black Friday-Verkaufs für ein Jahresabonnement angemeldet, da ich ein AI-Programmiertool ausprobieren wollte.
Ich habe mich dafür entschieden, weil ich keinen leistungsfähigen Computer habe,
- Ausführung und Ergebnisprüfung im Browser, ohne Compiler oder Interpreter lokal installieren zu müssen
- Lernen Sie Programmieren, ohne sich um die Konfiguration sorgen zu müssen.
- Gemeinschaftliche Codierungsprojekte. (Wenn ich den Link teile, können wir gemeinsam Pair Programming betreiben) - Bei Bedarf kann jeder mitmachen.
- Schnelle Prototypenerstellung und -prüfung von Code.
- Interaktives Unterrichten von Codierung für Schüler.
- Hosting von leichtgewichtigen Webanwendungen oder APIs.
Ich sollte damit auch mal ein Video drehen. https://replit.com/
Die Welt betrachten (verschiedene Nachrichten)
Wirtschaft
2024-11-29 (Fr) Morgenroutine (Hankyeong) : Zinssenkung in Korea von 3,25 % auf 3,0 % / zunehmende Einkommensungleichheit, sinkender Konsum / Exoskelett (Wearable Robot) / ETF mit bedingten Aktien 20% im Aufwind (angeblich gekauft von Ausländern)
>> Letztendlich gibt es keine Möglichkeit, den Aktienkurs zu steigern, wenn Ausländer nicht kaufen.
IT
- 지금 주목해야 할 ‘생성 AI 소비 트렌드’ TOP 4 | 요즘IT
- 미국의 주요 기업들이 올해 3분기 실적을 발표했습니다. 실적 발표 자리에서 소위 빅테크 기업들은 생성 AI에 대한 투자를 지속할 것임을 예고했습니다. 천문학적인 금액이 쏟아지고 있는 만큼, 생성 AI 산업을 구성하는 트렌드는 빠른 속도로 변화하고 있는데요. 이번 글에서는 지난 8월 안드레센 호로위츠가 발표한 자료를 토대로 사용자들이 실제 어떤 생성 AI 서비스를 사용하고 있는지, 소비 트렌드를 살펴보고자 합니다.
- 코드 작성 시간 절반으로 줄여줄 5가지 개발 툴 | 요즘IT
- 여러분은 매일 코드 작성과 디버깅에 얼마나 많은 시간을 소비하나요? 지금부터 소개해 드릴 AI와 자동화 툴 5가지만 제대로 활용해도 그 시간을 절반으로 줄일 수 있습니다. 개발자의 하루는 해결해야 할 문제로 가득하니까요. 코드 작성을 도와주는 GitHub Copilot부터 코드 품질을 한눈에 개선해 주는 SonarQube까지. 이 툴들은 어떻게 여러분의 개발 생산성과 코드 품질을 끌어올려 줄까요?
10 Gewohnheiten, die gute Entwickler befolgen sollten
>> Genau das habe ich beim Erstellen und Pflegen der Telematik-/Clusterplattform festgestellt, aber ich konnte es nicht richtig umsetzen. Man sollte Veränderungen nicht fürchten, und wenn man sie wie hier in kleine Teile zerlegt, scheint es möglich zu sein.
Originaltext: Koreanisch, Englisch
1. Halten Sie Ihre Commits so klein wie möglich, sogar so klein, dass Sie sich fragen "Kann man das so klein machen?"
Man weiß nie, wann man eine bestimmte Änderung rückgängig machen muss. Zu wissen, wo genau ein vor sechs Tagen aufgetretener Fehler liegt und diesen Commit ohne komplexe Merge-Konflikte rückgängig machen zu können, ist eine große Erleichterung. Mein Maßstab ist einfach: Code, der kompiliert, kann committet werden.
2. Befolgen Sie Kents Becks Maxime: "Um die gewünschte Änderung vorzunehmen, vereinfachen Sie zuerst die Änderung (Vorsicht: Das kann schwierig sein) und nehmen Sie dann die vereinfachte Änderung vor."
"Um die gewünschte Änderung vorzunehmen, vereinfachen Sie zuerst die Änderung (Vorsicht: Das kann schwierig sein) und nehmen Sie dann die vereinfachte Änderung vor."
Achten Sie darauf, dass mehr als die Hälfte Ihrer Commits Refactorings sind. Kontinuierliches Refactoring bedeutet, Verbesserungen zu finden und anzuwenden, die innerhalb von 10 Minuten durchgeführt werden können. Dank dieser kleinen Verbesserungen können Sie später auch bei großen Anforderungen mit einfachen Änderungen auskommen. Groß angelegte Refactorings sollten vermieden werden.
3. Jeder Code ist eine Schuld.
Nicht bereitgestellter Code ist die Schuld der Schulden. Sie müssen überprüfen, ob der Code ordnungsgemäß funktioniert und zumindest keine anderen Funktionen beeinträchtigt. Tests geben Ihnen Vertrauen und Produktionsbereitstellungen bieten Validierung. Häufige Bereitstellungen können die Hosting-Kosten etwas erhöhen, aber es lohnt sich, zu wissen, dass die letzte Arbeit tatsächlich Fortschritte gebracht hat. Einer der agilen Grundsätze lautet: "Funktionsfähige Software ist das wichtigste Maß für den Fortschritt". Die Wörter "funktionierend" und "Fortschritt" haben hier eine zentrale Bedeutung, daher habe ich meine eigene Definition geschaffen. "Funktionierend" bedeutet bereitgestellt werden zu können, und jeder Code, der zu einer Funktion beiträgt, ist ein "Fortschritt".
4. Fragen Sie sich, ob Sie die Funktionen des Frameworks testen. Wenn ja, lassen Sie es sein.
Das Framework wurde bereits von weitaus professionelleren Leuten als Sie getestet, und Sie sollten darauf vertrauen, dass der useState()-Hook wie vorgesehen funktioniert. Wenn Sie die Komponenten klein halten, erledigt das Framework die meisten wichtigen Aufgaben, sodass Sie nicht viele Tests benötigen. Wenn Komponenten größer werden, steigt die Komplexität, und Sie müssen entsprechend mehr Tests schreiben.
5. Wenn eine bestimmte Funktion nirgendwo passt, erstellen Sie ein neues Modul (oder eine Klasse oder Komponente) und finden Sie später die richtige Position.
Es ist besser, eine neue unabhängige Struktur zu erstellen, als etwas mit Gewalt an eine Stelle zu zwängen, an der es nicht hingehört. Selbst im schlimmsten Fall ist es nicht so schlimm, als unabhängiges Modul zu existieren.
6. Wenn Sie nicht wissen, wie eine API aussehen soll, schreiben Sie zuerst den Test.
Dies zwingt Sie, in diesem Fall aus der Perspektive Ihres eigenen "Kunden" zu denken. Wenn Sie zuerst den Code geschrieben und dann getestet hätten, könnten Sie Fälle entdecken, die Sie sonst nicht gefunden hätten. Sie müssen nicht zu dogmatisch an TDD herangehen, und Sie können auch in größeren Einheiten arbeiten (z. B. mehrere Codezeilen schreiben, bevor der Test bestanden ist). Die Menge an Code im Fehlerzustand muss nicht immer gering sein. Wenn Sie wissen, was Sie tun, lassen Sie die Prinzipien nicht Ihre Produktivität beeinträchtigen.
7. Kopieren und Einfügen ist einmal in Ordnung.
Führen Sie keine zweite Duplizierung (d. h. die dritte Kopie) durch. Zu diesem Zeitpunkt gibt es genügend Beispiele, um eine gute Abstraktion zu erstellen. Da das Risiko, dass Implementierungen derselben Funktion voneinander abweichen, zu groß ist, ist eine Integration erforderlich. Eine etwas unbeholfene Parametrisierung ist besser, als dieselbe Funktion mehrmals zu implementieren. Wenn diese Situation erneut auftritt, ist es einfacher, die Parameter zu verbessern, als vier verschiedene Implementierungen zu integrieren.
8. Designs altern.
Durch Refactoring kann man die Geschwindigkeit verlangsamen, aber irgendwann muss man die Funktionsweise ändern. Seien Sie nicht zu traurig, wenn Sie etwas, das Sie früher geschätzt und auf das Sie stolz waren, aufgeben müssen. Damals haben Sie Ihr Bestes gegeben, und Sie müssen sich nicht selbst beschimpfen, weil Sie es nicht perfekt gemacht haben, um keine Änderungen vornehmen zu müssen. Der größte Teil der Softwareentwicklung besteht darin, Software zu ändern. Akzeptieren Sie das und machen Sie weiter. Es gibt kein perfektes Design, und Änderungen sind der Kern der Softwareentwicklung. Ihr Können als Entwickler bestimmt sich danach, wie gut Sie Änderungen vornehmen können.
9. Technische Schulden lassen sich in drei Kategorien einteilen:
1) Dinge, die die aktuelle Arbeit behindern, 2) Dinge, die zukünftige Arbeit behindern werden, 3) Dinge, die zukünftige Arbeit behindern könnten. Alle anderen Klassifizierungen sind Untermengen dieser drei. Minimieren Sie #1 und konzentrieren Sie sich auf #2. Kümmern Sie sich nicht um #3.
10. Testbarkeit ist eng mit gutem Design verbunden.
Die Unfähigkeit, leicht zu testen, ist ein Zeichen dafür, dass das Design geändert werden muss. Manchmal kann es sich dabei um ein Testdesign handeln. Wenn es beispielsweise schwierig ist, em.getRepository(User).findOneOrFail({id}) zu mocken, ist es besser, diesen Aufruf in eine separat mockbare Funktion auszulagern oder ein Test-Utility zu schreiben, mit dem sich Entity-Manager-Methoden einfach mocken lassen. Tests werden nicht deshalb nicht geschrieben, weil man keine Lust zum Testen hat, sondern weil sie schwierig zu testen sind.
Kommentare0