- Replit – Build apps and sites with AI
- Replit is an AI-powered platform for building professional web apps and websites.
Berlangganan Replit Premium selama 1 Tahun
Saya berlangganan karena ingin mencoba alat pemrograman AI, dan memanfaatkan diskon Black Friday hingga 1 Desember.
Alasan saya memilih ini adalah karena saya tidak memiliki komputer yang memadai,
- Tidak perlu menginstal kompiler atau interpreter secara lokal, eksekusi dan pengecekan hasil dapat dilakukan di browser.
- Pelajari pemrograman tanpa perlu khawatir tentang konfigurasi lingkungan.
- Proyek pengkodean bersama. (Saya dapat berbagi tautan sehingga kita dapat melakukan pair programming) - Jika diperlukan, siapa pun dapat bergabung.
- Prototyping dan pengujian kode yang cepat.
- Mengajarkan pengkodean kepada siswa dengan cara interaktif.
- Hosting aplikasi web atau API yang ringan.
Saya juga harus membuat video tentang ini nanti. https://replit.com/
Melihat Dunia. (Berbagai Berita)
Ekonomi
2024-11-29 (Jum) Rutinitas Pagi (Hankyeong) : Penurunan suku bunga Korea 3,25% -> 3,0% / Kesenjangan pendapatan meningkat, penurunan konsumsi / X-ble Shoulder (robot yang dapat dikenakan) / ETF saham bertema 20% melaju (kabarnya dibeli oleh investor asing)
>> Pada akhirnya, jika investor asing tidak membelinya, tidak ada cara untuk menaikkan harga saham.
TI
- 지금 주목해야 할 ‘생성 AI 소비 트렌드’ TOP 4 | 요즘IT
- 미국의 주요 기업들이 올해 3분기 실적을 발표했습니다. 실적 발표 자리에서 소위 빅테크 기업들은 생성 AI에 대한 투자를 지속할 것임을 예고했습니다. 천문학적인 금액이 쏟아지고 있는 만큼, 생성 AI 산업을 구성하는 트렌드는 빠른 속도로 변화하고 있는데요. 이번 글에서는 지난 8월 안드레센 호로위츠가 발표한 자료를 토대로 사용자들이 실제 어떤 생성 AI 서비스를 사용하고 있는지, 소비 트렌드를 살펴보고자 합니다.
- 코드 작성 시간 절반으로 줄여줄 5가지 개발 툴 | 요즘IT
- 여러분은 매일 코드 작성과 디버깅에 얼마나 많은 시간을 소비하나요? 지금부터 소개해 드릴 AI와 자동화 툴 5가지만 제대로 활용해도 그 시간을 절반으로 줄일 수 있습니다. 개발자의 하루는 해결해야 할 문제로 가득하니까요. 코드 작성을 도와주는 GitHub Copilot부터 코드 품질을 한눈에 개선해 주는 SonarQube까지. 이 툴들은 어떻게 여러분의 개발 생산성과 코드 품질을 끌어올려 줄까요?
10 Kebiasaan yang Harus Diikuti untuk Menjadi Pengembang yang Baik
>> Itulah yang saya rasakan saat membuat dan memelihara platform telematika/cluster, tetapi saya tidak dapat menjalankannya dengan benar. Saya tidak boleh takut akan perubahan, dan jika saya membaginya seperti ini, saya rasa itu akan berhasil.
Sumber asli: Bahasa Korea , Bahasa Inggris
1. Pertahankan ukuran komit sekecil mungkin, sampai-sampai Anda berpikir "Apakah ini cukup kecil?"
Karena Anda tidak pernah tahu kapan Anda perlu mengembalikan perubahan tertentu. Mengetahui lokasi tepat bug yang terjadi 6 hari yang lalu, dan dapat mengembalikan hanya komit tersebut tanpa konflik penggabungan yang rumit, memberikan rasa aman yang besar. Kriteria saya sederhana: kode yang dapat dikompilasi dapat di-komit.
2. Praktikkan pepatah Kent Beck: "Untuk membuat perubahan yang diinginkan, pertama-tama buat perubahan itu mudah (peringatan: ini bisa sulit), lalu lakukan perubahan yang telah dipermudah."
"Untuk membuat perubahan yang diinginkan, pertama-tama buat perubahan itu mudah (peringatan: ini bisa sulit), lalu lakukan perubahan yang telah dipermudah."
Buat lebih dari setengah dari semua komit Anda menjadi refactoring. Refactoring berkelanjutan adalah tentang menemukan dan menerapkan peningkatan yang dapat dilakukan dalam waktu kurang dari 10 menit. Karena peningkatan kecil ini, Anda dapat menyelesaikan persyaratan besar nanti hanya dengan perubahan kecil. Refactoring skala besar harus dihindari.
3. Semua kode adalah hutang.
Kode yang tidak di-deploy adalah hutang atas hutang. Anda perlu memastikan bahwa kode tersebut berfungsi dengan baik, setidaknya tidak merusak fungsi lain. Pengujian memberikan kepercayaan diri, dan deployment produksi memberikan validasi. Biaya hosting mungkin sedikit meningkat dengan deployment yang sering, tetapi layak untuk memastikan bahwa pekerjaan terakhir adalah kemajuan nyata. Salah satu prinsip Agile adalah "Perangkat lunak yang berfungsi adalah ukuran kemajuan utama". Kata-kata 'berfungsi' dan 'kemajuan' memiliki arti penting di sini, jadi saya membuat definisi saya sendiri. 'Berfungsi' berarti dapat di-deploy, dan kode yang berkontribusi pada fungsi apa pun adalah 'kemajuan'.
4. Tanyakan pada diri Anda sendiri apakah Anda sedang menguji fungsi kerangka kerja. Jika ya, jangan lakukan itu.
Kerangka kerja telah diuji oleh orang-orang yang jauh lebih profesional daripada Anda, dan Anda harus mempercayai bahwa hook useState() berfungsi seperti yang dimaksudkan. Dengan menjaga komponen tetap kecil, kerangka kerja menangani sebagian besar pekerjaan inti, sehingga tidak banyak pengujian yang diperlukan. Saat komponen menjadi lebih besar, kompleksitas meningkat dan Anda perlu menulis lebih banyak pengujian.
5. Jika fungsi tertentu tidak cocok di mana pun, buat modul (atau kelas atau komponen) baru dan temukan lokasi yang tepat nanti.
Lebih baik membuat struktur independen baru daripada memaksakannya ke tempat yang menurut Anda tidak cocok. Bahkan dalam kasus terburuk, tetap sebagai modul independen bukanlah hal yang buruk.
6. Jika Anda tidak tahu seperti apa API itu, tulis pengujian terlebih dahulu.
Ini membuat Anda berpikir dari sudut pandang "pelanggan" Anda sendiri dalam hal ini. Anda dapat menemukan kasus yang mungkin tidak akan Anda temukan jika Anda menulis kode terlebih dahulu dan kemudian mengujinya. Anda tidak perlu terlalu dogmatis tentang TDD, dan Anda dapat mengerjakan unit yang lebih besar (misalnya, menulis beberapa baris kode sebelum pengujian lulus). Jumlah kode dalam keadaan gagal tidak harus selalu sedikit. Jika Anda tahu apa yang Anda lakukan, jangan biarkan prinsip menghambat produktivitas Anda.
7. Menyalin dan menempel sekali saja tidak apa-apa.
Jangan melakukan duplikasi kedua (yaitu, salinan ketiga). Pada titik ini, Anda akan memiliki contoh yang cukup untuk membuat abstraksi yang baik. Integrasi diperlukan karena risiko implementasi fungsi yang sama menjadi berbeda terlalu besar. Parameterisasi yang agak canggung lebih baik daripada mengimplementasikan fungsi yang serupa beberapa kali. Jika situasi ini terjadi lagi, akan lebih mudah untuk meningkatkan parameter daripada mengintegrasikan empat implementasi yang berbeda.
8. Desain akan menjadi usang.
Refactoring dapat memperlambat kecepatannya, tetapi pada akhirnya, Anda perlu mengubah cara kerjanya. Jangan terlalu sedih ketika Anda harus membuang sesuatu yang pernah Anda hargai dan banggakan. Anda telah melakukan yang terbaik pada saat itu, dan Anda tidak perlu menyalahkan diri sendiri karena tidak dapat membuatnya sempurna sehingga tidak perlu diubah. Sebagian besar pengembangan perangkat lunak adalah tentang mengubah perangkat lunak. Terima itu dan terus maju. Tidak ada desain yang sempurna, dan perubahan adalah inti dari pengembangan perangkat lunak. Seberapa mahir Anda dalam mengubah menentukan kemampuan Anda sebagai pengembang.
9. Hutang teknis dapat diklasifikasikan menjadi tiga:
1) Hal-hal yang mengganggu pekerjaan saat ini, 2) Hal-hal yang akan mengganggu pekerjaan di masa mendatang, 3) Hal-hal yang dapat mengganggu pekerjaan di masa mendatang. Semua klasifikasi lain adalah subset dari tiga hal ini. Minimalkan #1 dan fokus pada #2. Jangan khawatir tentang #3.
10. Testabilitas sangat terkait dengan desain yang baik.
Tidak dapat menguji dengan mudah adalah sinyal bahwa Anda perlu mengubah desain. Terkadang desain tersebut mungkin desain pengujian. Misalnya, jika sulit untuk mengejek em.getRepository(User).findOneOrFail({id}), lebih baik untuk memisahkan panggilan tersebut ke dalam fungsi terpisah yang dapat diejek atau menulis utilitas pengujian yang dapat mengejek metode entity manager dengan mudah. Alasan mengapa pengujian tidak ditulis bukanlah karena Anda tidak ingin mengujinya, tetapi karena sulit untuk mengujinya.
Komentar0