- Replit – Build apps and sites with AI
- Replit is an AI-powered platform for building professional web apps and websites.
Replit - roczny abonament płatny
Zdecydowałem się na roczną subskrypcję Replita do 1/12 ze względu na promocję Black Friday, ponieważ chciałem przetestować narzędzie do programowania AI.
Wybrałem to rozwiązanie, ponieważ nie posiadam porządnego komputera,
- uruchamianie i sprawdzanie wyników w przeglądarce bez konieczności instalowania kompilatorów lub interpreterów lokalnie
- nauka programowania bez obaw o konfigurację środowiska.
- wspólne projekty kodowania. (Mogę udostępnić link, aby umożliwić programowanie w parach) - jeśli chcesz, możemy razem to zrobić.
- szybkie tworzenie prototypów i testowanie kodu.
- interaktywne nauczanie kodowania studentów.
- hosting lekkich aplikacji webowych lub API.
W przyszłości będę musiał nagrać z tego też filmik. https://replit.com/
Spójrzmy na świat. (Różne wiadomości)
Gospodarka
2024-11-29 (pt) Poranna rutyna (Koreańska Gospodarka) : obniżka stóp procentowych w Korei z 3,25% na 3,0% / wzrost nierówności dochodów, spadek konsumpcji / X-ble Shoulder (robotyczny egzoszkielet) / ETF o tematyce warunkowej 20% w górę (podobno kupują je obcokrajowcy)
>> Ostatecznie, jeśli obcokrajowcy nie kupują, nie ma sposobu na wzrost cen akcji.
IT
- 지금 주목해야 할 ‘생성 AI 소비 트렌드’ TOP 4 | 요즘IT
- 미국의 주요 기업들이 올해 3분기 실적을 발표했습니다. 실적 발표 자리에서 소위 빅테크 기업들은 생성 AI에 대한 투자를 지속할 것임을 예고했습니다. 천문학적인 금액이 쏟아지고 있는 만큼, 생성 AI 산업을 구성하는 트렌드는 빠른 속도로 변화하고 있는데요. 이번 글에서는 지난 8월 안드레센 호로위츠가 발표한 자료를 토대로 사용자들이 실제 어떤 생성 AI 서비스를 사용하고 있는지, 소비 트렌드를 살펴보고자 합니다.
- 코드 작성 시간 절반으로 줄여줄 5가지 개발 툴 | 요즘IT
- 여러분은 매일 코드 작성과 디버깅에 얼마나 많은 시간을 소비하나요? 지금부터 소개해 드릴 AI와 자동화 툴 5가지만 제대로 활용해도 그 시간을 절반으로 줄일 수 있습니다. 개발자의 하루는 해결해야 할 문제로 가득하니까요. 코드 작성을 도와주는 GitHub Copilot부터 코드 품질을 한눈에 개선해 주는 SonarQube까지. 이 툴들은 어떻게 여러분의 개발 생산성과 코드 품질을 끌어올려 줄까요?
10 nawyków, których należy przestrzegać, aby zostać dobrym programistą
>> To, co poczułem, tworząc i utrzymując platformę telematyczną / klasterową, ale czego nie mogłem w pełni wdrożyć. Nie należy bać się zmian, a podział na mniejsze części, tak jak tutaj, wydaje się możliwy do wykonania.
Oryginał: Wersja polska, Wersja angielska
1. Zachowuj jak najmniejsze komity, aż do momentu, gdy pomyślisz "Czy na pewno tak mały commit?"
Nigdy nie wiadomo, kiedy trzeba będzie cofnąć określone zmiany. Wiedza o tym, gdzie dokładnie znajdował się błąd sprzed 6 dni i możliwość jego cofnięcia bez złożonych konfliktów scalania to ogromna ulga. Moje kryterium jest proste: kod, który się kompiluje, może zostać zatwierdzony.
2. Postępuj zgodnie z zasadą Kenta Becka: "Aby wykonać pożądaną zmianę, najpierw ułatw sobie tę zmianę (uwaga: to może być trudne), a następnie dokonaj ułatwionej zmiany."
"Aby wykonać pożądaną zmianę, najpierw ułatw sobie tę zmianę (uwaga: to może być trudne), a następnie dokonaj ułatwionej zmiany."
Zadbaj o to, aby ponad połowa wszystkich commitów była refaktoryzacją. Ciągła refaktoryzacja to znajdowanie i wprowadzanie poprawek w ciągu 10 minut. Te małe ulepszenia pozwolą na rozwiązanie większych problemów za pomocą prostych zmian w przyszłości. Należy unikać dużych refaktoryzacji.
3. Każdy kod to dług techniczny.
Niezainstalowany kod to dług techniczny w dług technicznym. Należy upewnić się, że kod działa poprawnie i przynajmniej nie psuje innych funkcji. Testy budują zaufanie, a wdrożenia produkcyjne zapewniają weryfikację. Częste wdrożenia mogą nieco zwiększyć koszty hostingu, ale świadomość, że ostatnia praca była realnym postępem, jest tego warta. Jedną z zasad Agile jest to, że "działający oprogramowanie jest głównym wskaźnikiem postępu". Słowa "działanie" i "postęp" mają tutaj kluczowe znaczenie, więc stworzyłem własną definicję. "Działanie" oznacza gotowość do wdrożenia, a każdy kod przyczyniający się do jakiejś funkcji to "postęp".
4. Zastanów się, czy testujesz funkcje frameworka. Jeśli tak, to nie rób tego.
Framework został już przetestowany przez osoby znacznie bardziej doświadczone niż ty, więc musisz zaufać, że hook useState() działa zgodnie z przeznaczeniem. Utrzymywanie komponentów w minimalnym rozmiarze oznacza, że framework zajmuje się większością kluczowych zadań, więc nie potrzeba wielu testów. Im większy komponent, tym większa złożoność i tym więcej testów należy napisać.
5. Jeśli dana funkcja nie pasuje nigdzie, utwórz nowy moduł (lub klasę, komponent) i znajdź odpowiednie miejsce później.
Lepiej jest stworzyć nową, niezależną strukturę niż na siłę wciskać ją w miejsce, w którym nie pasuje. Nawet w najgorszym przypadku pozostanie niezależnym modułem, co nie jest złe.
6. Jeśli nie wiesz, jak powinien wyglądać API, napisz najpierw test.
To zmusi cię do myślenia z perspektywy "klienta", którym w tym przypadku jesteś ty sam. Możesz znaleźć przypadki, których nie znalazłbyś, gdybyś najpierw napisał kod, a później test. Nie musisz być zbyt dogmatyczny w TDD, możesz pracować w większych jednostkach (np. pisać kilka linii kodu przed przejściem testu). Ilość kodu w stanie błędnym nie musi być zawsze mała. Jeśli wiesz, co robisz, nie pozwól, aby zasady ograniczały twoją produktywność.
7. Kopiowanie-wklejanie jest w porządku raz.
Nie rób tego drugi raz (czyli trzecie kopiowanie). W tym momencie masz wystarczająco dużo przykładów, aby stworzyć dobrą abstrakcję. Ryzyko, że implementacje tej samej funkcji będą się od siebie różnić, jest zbyt duże, dlatego integracja jest niezbędna. Lepiej jest mieć nieco nieporęczną parametryzację niż wielokrotnie implementować podobne funkcje. Jeśli taka sytuacja się powtórzy, łatwiej będzie ulepszyć parametry niż integrować cztery różne implementacje.
8. Projekty się starzeją.
Refaktoryzacja może spowolnić ten proces, ale ostatecznie trzeba będzie zmienić sposób działania. Nie smuć się zbytnio, gdy będziesz musiał porzucić to, co kiedyś było cenne i budziło dumę. W tamtym czasie zrobiłeś wszystko, co w twojej mocy, i nie musisz obwiniać się za to, że nie zrobiłeś tego idealnie. Większość programowania to modyfikacja oprogramowania. Zaakceptuj to i idź do przodu. Nie ma idealnego projektu, a zmiana jest kluczowa w programowaniu. Twoje umiejętności programisty zależą od tego, jak dobrze potrafisz wprowadzać zmiany.
9. Dług techniczny można podzielić na trzy kategorie:
1) To, co przeszkadza w bieżącej pracy, 2) To, co będzie przeszkadzać w przyszłej pracy, 3) To, co może przeszkadzać w przyszłej pracy. Wszystkie inne klasyfikacje są podzbiorami tych trzech. Zminimalizuj #1, skup się na #2, zignoruj #3.
10. Testowalność jest ściśle związana z dobrym projektem.
Trudność w testowaniu jest sygnałem, że należy zmienić projekt. Czasami może to być projekt testu. Na przykład, jeśli trudno jest mockować em.getRepository(User).findOneOrFail({id}), lepiej jest wyodrębnić to wywołanie do oddzielnej funkcji, którą można łatwo mockować, lub napisać narzędzie testowe, które ułatwi mockowanie metod menedżera encji. Brak testów nie wynika z niechęci do pisania testów, ale z trudności w ich napisaniu.
Komentarze0