- Replit – Build apps and sites with AI
- Replit is an AI-powered platform for building professional web apps and websites.
Replit éves fizetős előfizetés
Egy AI programozási eszközt ki akartam próbálni, ezért feliratkoztam, mivel november 12-ig Black Friday (Fekete Péntek) akció volt.
Ezt azért választottam, mert nincs megfelelő számítógépem,
- nincs szükség a fordító vagy értelmező helyi telepítésére, a böngészőben futtatható és ellenőrizhető az eredmény
- beállítási aggodalmak nélkül tanulhat programozni.
- Közös kódolási projekt. (Ha megosztom a linket, együtt tudunk párban programozni) - Szükség esetén bárkivel együtt dolgozom.
- A kód gyors prototípuskészítése és tesztelése.
- Interaktív módon taníthatok programozni a diákoknak.
- Könnyű webes alkalmazások vagy API-k üzemeltetése.
Ezzel majd videót is készítenék. https://replit.com/
Nézzük meg a világot. (Különféle hírek)
Gazdaság
2024-11-29 (péntek) Reggel rutin (Hankyung) : Koreai kamatláb csökkentés 3,25% -> 3,0% / Jövedelmi egyenlőtlenség növekedése, fogyasztás csökkenése / X-ble Shoulder (viselhető robot) / Feltételes ETF 20%-os menetelés (a külföldiek veszik).
>> Végülis ha a külföldiek nem vesznek, nincs esély a részvényárak emelkedésére.
IT
- 지금 주목해야 할 ‘생성 AI 소비 트렌드’ TOP 4 | 요즘IT
- 미국의 주요 기업들이 올해 3분기 실적을 발표했습니다. 실적 발표 자리에서 소위 빅테크 기업들은 생성 AI에 대한 투자를 지속할 것임을 예고했습니다. 천문학적인 금액이 쏟아지고 있는 만큼, 생성 AI 산업을 구성하는 트렌드는 빠른 속도로 변화하고 있는데요. 이번 글에서는 지난 8월 안드레센 호로위츠가 발표한 자료를 토대로 사용자들이 실제 어떤 생성 AI 서비스를 사용하고 있는지, 소비 트렌드를 살펴보고자 합니다.
- 코드 작성 시간 절반으로 줄여줄 5가지 개발 툴 | 요즘IT
- 여러분은 매일 코드 작성과 디버깅에 얼마나 많은 시간을 소비하나요? 지금부터 소개해 드릴 AI와 자동화 툴 5가지만 제대로 활용해도 그 시간을 절반으로 줄일 수 있습니다. 개발자의 하루는 해결해야 할 문제로 가득하니까요. 코드 작성을 도와주는 GitHub Copilot부터 코드 품질을 한눈에 개선해 주는 SonarQube까지. 이 툴들은 어떻게 여러분의 개발 생산성과 코드 품질을 끌어올려 줄까요?
10 szokás, amelyeket be kell tartani egy jó fejlesztővé váláshoz
>> A telematikai/fürt platform létrehozása és karbantartása közben én is ezt éreztem, de nem tudtam megfelelően végrehajtani. Nem szabad félnünk a változástól, és ha, mint itt, apró részekre bontjuk a feladatot, akkor sikerülhet.
1. "Ennyire kicsiben is meg lehet csinálni?" - a lehető legkisebb commit-okat használja.
Soha nem lehet tudni, mikor kell majd visszavonni egy adott módosítást. Nagy megnyugvást jelent, ha tudjuk, hol van egy 6 nappal ezelőtti hiba, és a bonyolult összefűzési konfliktusok nélkül csak az adott commitot kell visszavonni. Az én kritériumom egyszerű: a fordítható kód commitolható.
2. Kövesse Kent Beck tanácsát: "A kívánt módosítás elvégzéséhez először könnyebbé tegye a módosítást (figyelem: ez nehéz lehet), majd végezze el a könnyebbé tett módosítást."
"A kívánt módosítás elvégzéséhez először könnyebbé tegye a módosítást (figyelem: ez nehéz lehet), majd végezze el a könnyebbé tett módosítást."
A commitok több mint felét refaktorálásnak kell képeznie. A folyamatos refaktorálás azt jelenti, hogy 10 percen belül megtalálható és alkalmazható a javítás. Ezek a kis javítások segítenek abban, hogy később, nagyobb igények esetén egyszerű módosításokkal is megoldható legyen a probléma. A nagyméretű refaktorálást el kell kerülni.
3. Minden kód adósság.
A ki nem telepített kód a legnagyobb adósság. Ellenőrizni kell, hogy a kód megfelelően működik-e, legalábbis nem töri-e meg más funkciókat. A tesztelés magabiztosságot ad, a termelésbe telepítés pedig validációt. A gyakori telepítés növelheti a hosting költségeket, de elegendő az a tudat, hogy az utolsó feladat valódi előrelépést jelentett. Az egyik agilis elv szerint "a működő szoftver a fejlődés legfontosabb mércéje". Itt a 'működik' és a 'fejlődés' szavak kulcsfontosságúak, ezért saját definíciót alkottam. A 'működik' a telepíthető szintet jelenti, és ha egy funkcióhoz járul hozzá a kód, az 'előrelépés'.
4. Gondolja át, hogy a keretrendszer funkcióit teszteli-e. Ha igen, ne tegye.
A keretrendszert már sokkal profibb emberek tesztelték, és bízni kell benne, hogy a useState() hook a várt módon működik. A kis komponensek esetén a keretrendszer elvégzi a legtöbb alapvető feladatot, ezért kevés tesztre van szükség. A komponensek növekedésével nő a komplexitás, és több tesztet kell írni.
5. Ha egy adott függvény sehova sem illik, hozzon létre egy új modult (vagy osztályt, vagy komponenst), és később keressen megfelelő helyet.
Jobb egy új, független struktúrát létrehozni, mint erőszakkal beilleszteni oda, ahová nem illik. A legrosszabb esetben is, ha független modulként marad, nem nagy baj.
6. Ha nem tudja, hogy az API-nak milyennek kell lennie, először írja meg a tesztet.
Ez arra kényszeríti, hogy a "vevő" nézőpontjából gondolkodjon (ez ebben az esetben maga is). Találhat olyan eseteket, amelyeket nem talált volna meg, ha először a kódot írta volna meg, és csak utána a tesztet. Nem kell dogmatikusnak lennie a TDD-vel kapcsolatban, nagyobb egységekkel is dolgozhat (pl.: több sor kód megírása a teszt sikeres lefutása előtt). Nem mindig kell kevés hibás kóddal dolgozni. Ha tudja, hogy mit csinál, ne engedje, hogy az elvek csökkentsék a termelékenységet.
7. A másolás-beillesztés egyszer megengedett.
A második ismétlésnél (tehát a harmadik másolásnál) ne tegye. Ekkor már elég példa van egy jó absztrakció létrehozásához. Túl nagy a kockázata annak, hogy a hasonló funkciójú implementációk eltérőek lesznek, ezért integrációra van szükség. Jobb egy kissé furcsa paraméterezés, mint több hasonló funkció többszöri implementálása. Ha ez a helyzet ismét előfordul, könnyebb lesz javítani a paramétereket, mint integrálni négy különböző implementációt.
8. A tervezés elavul.
A refaktorálás lassíthatja az elavulást, de végül meg kell változtatni a működési módot. Ne legyen túl szomorú, amikor el kell dobni azt, amit korábban értékesnek és nagyszerűnek tartott. Akkor mindent megtett, és nem kell emiatt önvádolással küszködni, mert nem volt tökéletes. A szoftverfejlesztés nagy része a szoftver módosításából áll. Fogadja el ezt, és haladjon előre. Nem létezik tökéletes tervezés, a módosítás a szoftverfejlesztés lényege. A képesség, hogy milyen ügyesen módosít, az határozza meg a fejlesztői képességeket.
9. A technikai adósság három kategóriába sorolható:
1) Azok, amelyek jelenleg akadályozzák a munkát, 2) Azok, amelyek a jövőbeli munkát akadályozzák, 3) Azok, amelyek akadályozhatják a jövőbeli munkát. Minden más besorolás ezen három alkészlet. Minimalizálja az #1-eseket, és koncentráljon a #2-esekre. A #3-asokra ne pazaroljon energiát.
10. A tesztelhetőség szorosan összefügg a jó tervezéssel.
Ha nehéz tesztelni, az azt jelenti, hogy meg kell változtatni a tervezést. Néha ez a teszttervezés lehet. Például, ha nehéz mockolni az em.getRepository(User).findOneOrFail({id}) metódust, akkor jobb, ha ezt a hívást egy külön, könnyen mockolható függvénybe helyezi, vagy teszt segédprogramot ír, amely könnyen mockolja az entitáskezelő metódusokat. A tesztek azért nem íródnak, mert nem akarnak tesztelni, hanem mert nehéz tesztelni.
Hozzászólások0