- Replit – Build apps and sites with AI
- Replit is an AI-powered platform for building professional web apps and websites.
Replit jaarabonnement
Ik heb me aangemeld tot 1 december vanwege de Black Friday-aanbieding, omdat ik een AI-programmeergereedschap wilde proberen.
De reden voor deze keuze is dat ik geen goede computer heb,
- Uitvoeren en resultaten controleren in de browser zonder dat compilers of interpreters lokaal hoeven te worden geïnstalleerd
- Leer programmeren zonder je zorgen te maken over configuratie.
- Gezamenlijke coderingsprojecten. (Als ik de link deel, kunnen we samen pair programming doen) - Iedereen is welkom om mee te doen als nodig.
- Snelle prototyping en testen van code.
- Coderen interactief aan studenten leren.
- Hosting van lichtgewicht webapplicaties of API's.
Ik moet hier binnenkort ook een video over maken. https://replit.com/
De wereld bekijken. (Verschillend nieuws)
Economie
2024-11-29 (vr) Ochtendroutine (Hankyeong) : Zuid-Koreaanse renteverlaging 3,25 -> 3,0% / Toenemende inkomensongelijkheid , afnemende consumptie / X-ble Shoulder (draagbare robot) / Voorwaardelijke ETF 20% goed gevaren (volgens zeggen buitenlanders kopen)
>> Uiteindelijk is er geen manier om de aandelenkoersen te laten stijgen als buitenlanders niet kopen.
IT
- 지금 주목해야 할 ‘생성 AI 소비 트렌드’ TOP 4 | 요즘IT
- 미국의 주요 기업들이 올해 3분기 실적을 발표했습니다. 실적 발표 자리에서 소위 빅테크 기업들은 생성 AI에 대한 투자를 지속할 것임을 예고했습니다. 천문학적인 금액이 쏟아지고 있는 만큼, 생성 AI 산업을 구성하는 트렌드는 빠른 속도로 변화하고 있는데요. 이번 글에서는 지난 8월 안드레센 호로위츠가 발표한 자료를 토대로 사용자들이 실제 어떤 생성 AI 서비스를 사용하고 있는지, 소비 트렌드를 살펴보고자 합니다.
- 코드 작성 시간 절반으로 줄여줄 5가지 개발 툴 | 요즘IT
- 여러분은 매일 코드 작성과 디버깅에 얼마나 많은 시간을 소비하나요? 지금부터 소개해 드릴 AI와 자동화 툴 5가지만 제대로 활용해도 그 시간을 절반으로 줄일 수 있습니다. 개발자의 하루는 해결해야 할 문제로 가득하니까요. 코드 작성을 도와주는 GitHub Copilot부터 코드 품질을 한눈에 개선해 주는 SonarQube까지. 이 툴들은 어떻게 여러분의 개발 생산성과 코드 품질을 끌어올려 줄까요?
10 gewoonten die je moet volgen om een goede ontwikkelaar te worden
>> Precies wat ik heb gevoeld tijdens het maken en onderhouden van het telematica/clusterplatform, maar ik kon het niet goed uitvoeren. We moeten verandering niet vrezen, en als we het zoals hier in kleine stukjes opsplitsen, zou het wel moeten lukken.
1. Houd commits zo klein mogelijk, zelfs als je denkt: "Mag dit wel zo klein?"
Je weet immers nooit wanneer je specifieke wijzigingen moet terugdraaien. Het is een enorme geruststelling om te weten waar een bug van 6 dagen geleden precies zat en die commit zonder ingewikkelde merge-conflicten terug te kunnen draaien. Mijn criterium is simpel: code die compileert, kan gecommit worden.
2. Volg het adagium van Kent Beck: "Maak de gewenste wijziging eerst gemakkelijk (let op: dit kan moeilijk zijn), en voer dan de gemakkelijke wijziging uit."
"Maak de gewenste wijziging eerst gemakkelijk (let op: dit kan moeilijk zijn), en voer dan de gemakkelijke wijziging uit."
Zorg ervoor dat meer dan de helft van je commits refactoring is. Continue refactoring betekent het vinden en toepassen van verbeteringen binnen 10 minuten. Dankzij deze kleine verbeteringen kun je later, bij grote verzoeken, met eenvoudige wijzigingen oplossen. Grote refactoring moet je vermijden.
3. Alle code is schuld.
Niet-uitgebrachte code is schuld bovenop schuld. Je moet controleren of de code goed werkt en ten minste geen andere functies beschadigt. Tests geven je vertrouwen en productieversies geven validatie. Hogere hostingkosten door frequente releases zijn het waard, want je weet zeker dat je laatste werk daadwerkelijke vooruitgang was. Een van de Agile-principes is dat "werkende software de belangrijkste maatstaf voor vooruitgang is". De woorden 'werkend' en 'vooruitgang' hebben hier een essentiële betekenis, dus heb ik mijn eigen definitie geformuleerd. 'Werkend' betekent deployment-klaar, en als een code bijdraagt aan een functie, is dat 'vooruitgang'.
4. Vraag jezelf af of je de functionaliteit van het framework aan het testen bent. Zo ja, doe dat dan niet.
Het framework is al getest door veel professionelere mensen dan jij, en je moet erop vertrouwen dat de useState()-hook zoals bedoeld werkt. Als je componenten klein houdt, doet het framework het meeste werk, waardoor je minder tests nodig hebt. Grotere componenten leiden tot meer complexiteit en dus meer tests.
5. Als een bepaalde functie nergens past, maak dan een nieuwe module (of klasse of component) en zoek later de juiste plek.
Het is beter om een nieuwe, onafhankelijke structuur te maken dan iets ergens met geweld in te proppen waar het niet past. Zelfs in het slechtste geval is het geen ramp om een onafhankelijke module te hebben.
6. Als je niet weet hoe een API eruit moet zien, schrijf dan eerst de test.
Dit dwingt je om na te denken vanuit het perspectief van de "klant", in dit geval jijzelf. Je vindt gevallen die je anders misschien gemist zou hebben als je eerst de code en dan de tests had geschreven. Je hoeft niet te dogmatisch te zijn over TDD; je kunt ook op een grotere schaal werken (bijv. meerdere regels code schrijven voordat de test slaagt). De hoeveelheid mislukte code hoeft niet altijd minimaal te zijn. Als je weet wat je doet, zorg er dan voor dat het principe je productiviteit niet schaadt.
7. Kopiëren-plakken is één keer prima.
Doe het niet een tweede keer (d.w.z. de derde kopie). Op dat moment heb je genoeg voorbeelden om een goede abstractie te maken. De kans dat implementaties van dezelfde functie van elkaar gaan verschillen is te groot, dus integratie is nodig. Een enigszins onhandige parametrisering is beter dan meerdere keren dezelfde functie implementeren. Als dit scenario zich herhaalt, is het gemakkelijker om de parameters te verbeteren dan vier verschillende implementaties samen te voegen.
8. Ontwerpen verouderen.
Met refactoring kun je de snelheid vertragen, maar uiteindelijk moet je de manier waarop het werkt veranderen. Wees niet te verdrietig als je iets moet weggooien dat je vroeger waardevol en geweldig vond. Je hebt er toen je best voor gedaan en je hoeft jezelf niet te verwijten dat het niet perfect was, zodat het niet hoefde te worden gewijzigd. Het grootste deel van softwareontwikkeling is het wijzigen van software. Accepteer dit en ga verder. Er is geen perfect ontwerp, en wijzigingen zijn de kern van softwareontwikkeling. Je vaardigheid om wijzigingen door te voeren bepaalt je vaardigheid als ontwikkelaar.
9. Technische schuld kan in drie categorieën worden ingedeeld:
1) Dingen die het huidige werk verstoren, 2) Dingen die toekomstig werk zullen verstoren, 3) Dingen die toekomstig werk zouden kunnen verstoren. Alle andere classificaties zijn subsets van deze drie. Minimaliseer #1 en concentreer je op #2. Maak je geen zorgen over #3.
10. Testbaarheid is nauw verbonden met goed ontwerp.
Moeilijk te testen is een teken dat het ontwerp moet worden gewijzigd. Soms kan dat testontwerp zijn. Als em.getRepository(User).findOneOrFail({id}) bijvoorbeeld moeilijk te mocken is, is het beter om die aanroep te scheiden in een aparte, mockbare functie of een test-utility te schrijven waarmee je EntityManager-methoden gemakkelijk kunt mocken. Tests worden niet weggelaten omdat ze niet leuk zijn om te schrijven, maar omdat ze moeilijk te schrijven zijn.
Reacties0