- Replit – Build apps and sites with AI
- Replit is an AI-powered platform for building professional web apps and websites.
Abbonamento Replit a pagamento per 1 anno
Ho effettuato l'iscrizione entro il 1° dicembre, approfittando dello sconto del Black Friday, perché avevo bisogno di provare uno strumento di programmazione AI.
La ragione di questa scelta è la mancanza di un computer adeguato,
- possibilità di eseguire e verificare i risultati nel browser, senza dover installare compilatori o interpreti localmente
- imparare a programmare senza preoccuparsi della configurazione dell'ambiente.
- progetti di coding collaborativi. (se condivido il link, è possibile effettuare pair programming) - chiunque abbia bisogno, può partecipare.
- prototipazione e test rapidi del codice.
- insegnamento della codifica agli studenti in modo interattivo.
- hosting di applicazioni web o API leggere.
Dovrei anche realizzare un video a riguardo. https://replit.com/
Osserviamo il mondo. (diverse notizie)
Economia
2024-11-29 (Ven) Morning Routine (Hankyeong) : riduzione dei tassi di interesse coreani da 3,25% a 3,0% / aumento della disparità di reddito, riduzione dei consumi / X-ble Shoulder (robot indossabile) / ETF azionario condizionato in crescita del 20% (apparentemente acquistati da investitori stranieri)
>> In definitiva, se gli investitori stranieri non acquistano, non c'è modo di far aumentare il prezzo delle azioni.
IT
- 지금 주목해야 할 ‘생성 AI 소비 트렌드’ TOP 4 | 요즘IT
- 미국의 주요 기업들이 올해 3분기 실적을 발표했습니다. 실적 발표 자리에서 소위 빅테크 기업들은 생성 AI에 대한 투자를 지속할 것임을 예고했습니다. 천문학적인 금액이 쏟아지고 있는 만큼, 생성 AI 산업을 구성하는 트렌드는 빠른 속도로 변화하고 있는데요. 이번 글에서는 지난 8월 안드레센 호로위츠가 발표한 자료를 토대로 사용자들이 실제 어떤 생성 AI 서비스를 사용하고 있는지, 소비 트렌드를 살펴보고자 합니다.
- 코드 작성 시간 절반으로 줄여줄 5가지 개발 툴 | 요즘IT
- 여러분은 매일 코드 작성과 디버깅에 얼마나 많은 시간을 소비하나요? 지금부터 소개해 드릴 AI와 자동화 툴 5가지만 제대로 활용해도 그 시간을 절반으로 줄일 수 있습니다. 개발자의 하루는 해결해야 할 문제로 가득하니까요. 코드 작성을 도와주는 GitHub Copilot부터 코드 품질을 한눈에 개선해 주는 SonarQube까지. 이 툴들은 어떻게 여러분의 개발 생산성과 코드 품질을 끌어올려 줄까요?
10 abitudini da seguire per diventare un buon sviluppatore
>> proprio questo è ciò che ho imparato creando e gestendo la piattaforma telematica/cluster, ma non sono riuscito a metterlo in pratica correttamente. Non dovremmo aver paura del cambiamento, e se lo dividiamo in piccole parti come qui, sembra fattibile.
Testo originale: Versione coreana, Versione inglese
1. Mantenete i commit piccoli, al punto da chiedervi: “Posso davvero farli così piccoli?”
Non si sa mai quando potrebbe essere necessario ripristinare una specifica modifica. Sapere esattamente dove si trova un bug di 6 giorni fa e poter ripristinare solo quel commit senza complessi conflitti di merge è una grande tranquillità. Il mio criterio è semplice: il codice che viene compilato può essere committato.
2. Mettete in pratica il detto di Kent Beck: “Per effettuare la modifica desiderata, rendete prima tale modifica più semplice (attenzione: questo potrebbe essere difficile), poi effettuate la modifica semplificata.”
"Per effettuare la modifica desiderata, rendete prima tale modifica più semplice (attenzione: questo potrebbe essere difficile), poi effettuate la modifica semplificata."
Fate in modo che oltre la metà dei commit totali siano di refactoring. Il refactoring continuo consiste nel trovare e applicare miglioramenti che possono essere eseguiti in meno di 10 minuti. Questi piccoli miglioramenti permettono di risolvere anche le grandi richieste future con semplici modifiche. I refactoring su larga scala devono essere evitati.
3. Tutto il codice è debito.
Il codice non distribuito è il debito dei debiti. È necessario verificare se il codice funziona correttamente e, almeno, non danneggia altre funzionalità. I test forniscono sicurezza e la distribuzione in produzione offre convalida. La frequenza delle distribuzioni potrebbe aumentare leggermente i costi di hosting, ma vale la pena farlo per la sicurezza di sapere che l'ultimo lavoro è stato un vero progresso. Uno dei principi Agile afferma che “il software funzionante è la misura principale del progresso”. In questo contesto, le parole “funzionamento” e “progresso” hanno un significato fondamentale, quindi ho dato loro una mia definizione. “Funzionamento” significa livello di distribuzione e, se un codice contribuisce a una funzione, esso rappresenta “progresso”.
4. Chiedetevi se state testando le funzionalità del framework. Se sì, non fatelo.
Il framework è già stato testato da persone molto più esperte di voi e dovreste fidarvi del fatto che l'hook useState() funzioni come previsto. Mantenendo i componenti piccoli, il framework si occupa della maggior parte delle attività principali, quindi non sono necessari molti test. All'aumentare delle dimensioni dei componenti, aumenta la complessità e di conseguenza è necessario scrivere più test.
5. Se una particolare funzione non si adatta a nessun luogo, create un nuovo modulo (o classe o componente) e cercate la posizione appropriata in seguito.
È meglio creare una nuova struttura indipendente rispetto a forzarne l'inserimento in un posto in cui non si adatta. Anche nel peggiore dei casi, rimanere un modulo indipendente non è così male.
6. Se non sapete quale dovrebbe essere l'aspetto di un'API, scrivete prima il test.
Questo vi costringe a pensare dal punto di vista del “cliente”, che in questo caso siete voi. Potreste trovare casi che non avreste scoperto se aveste scritto prima il codice e poi il test. Non è necessario essere troppo dogmatici sul TDD ed è accettabile lavorare su unità più grandi (es. scrivere più righe di codice prima che il test passi). La quantità di codice in stato di errore non deve essere sempre bassa. Se sapete cosa state facendo, assicuratevi che i principi non ostacolino la produttività.
7. Copiare e incollare una volta va bene.
Non fate una seconda duplicazione (cioè, una terza copia). A questo punto, avrete abbastanza esempi per creare una buona astrazione. L'integrazione è necessaria perché il rischio che le implementazioni della stessa funzionalità siano diverse è troppo elevato. Una parametrizzazione leggermente goffa è migliore rispetto all'implementazione di funzionalità simili più volte. Se questa situazione si ripresenta, sarà più facile migliorare i parametri che integrare quattro diverse implementazioni.
8. Il design tende a invecchiare.
Il refactoring può rallentarne la velocità, ma alla fine dovrete cambiare il modo in cui funziona. Non disperate troppo quando dovrete abbandonare ciò che una volta era prezioso e di cui andavate fieri. All'epoca avete fatto del vostro meglio e non dovete incolparvi per non essere riusciti a renderlo perfetto al punto da non richiedere modifiche. Gran parte dello sviluppo software consiste nel modificare il software. Accettatelo e andate avanti. Non esiste un design perfetto e la modifica è il cuore dello sviluppo software. La vostra capacità di sviluppatore è determinata dalla vostra abilità nel gestire le modifiche.
9. Il debito tecnico può essere classificato in tre modi:
1) ciò che ostacola il lavoro attuale, 2) ciò che ostacolerà il lavoro futuro, 3) ciò che potrebbe ostacolare il lavoro futuro. Tutte le altre classificazioni sono sottoinsiemi di queste tre. Minimizzate #1 e concentratevi su #2. Non preoccupatevi di #3.
10. La testabilità è strettamente correlata a un buon design.
La difficoltà di eseguire i test è un segnale che il design deve essere modificato. A volte, il design potrebbe essere il design del test. Ad esempio, se è difficile effettuare il mocking di em.getRepository(User).findOneOrFail({id}), è meglio separare tale chiamata in una funzione separata che può essere facilmente mockata o creare un'utility di test che permetta di mockare facilmente i metodi dell'entity manager. Il motivo per cui i test non vengono scritti non è la mancanza di voglia di scriverli, ma la difficoltà di scriverli.
Commenti0