- Replit – Build apps and sites with AI
- Replit is an AI-powered platform for building professional web apps and websites.
Replit'e 1 Yıllık Ücretli Abonelik
Yapay zekâ programlama aracını denemem gerektiğini düşündüğüm için, 1 Aralık'a kadar süren Black Friday indirimi nedeniyle abone oldum.
Bunu seçmemin sebebi, benim düzgün bir bilgisayarım olmamasıydı,
- Derleyici veya yorumlayıcıları yerel olarak kurmaya gerek kalmadan tarayıcıda çalıştırma ve sonuçları kontrol etme
- Kurulum endişesi olmadan programlamayı öğrenin.
- Ortak kodlama projeleri. (Bağlantıyı paylaştığımda birlikte eşli programlama yapabiliriz) - İhtiyaç duyulursa herkes birlikte yapsın.
- Kodun hızlı prototipleme ve testi.
- Öğrencilere interaktif bir şekilde kodlama öğretme.
- Hafif web uygulamaları veya API barındırma.
Bundan sonra bununla ilgili bir video da çekmeliyim. https://replit.com/
Dünyaya Bakalım. (Çeşitli Haberler)
Ekonomi
2024-11-29 (Cum) Sabah Rutini (Hankyeong) : Kore faiz indirimi %3,25 -> %3,0 / Gelir eşitsizliği artışı, tüketim azalması / Exoskeleton (giyilebilir robot) / Koşullu hisse senedi ETF'si %20 ilerleme (Yabancıların aldığı söyleniyor)
>> Sonuç olarak, yabancılar almazsa hisse senedi fiyatının yükselmesinin bir yolu yok.
Bilişim Teknolojileri
- 지금 주목해야 할 ‘생성 AI 소비 트렌드’ TOP 4 | 요즘IT
- 미국의 주요 기업들이 올해 3분기 실적을 발표했습니다. 실적 발표 자리에서 소위 빅테크 기업들은 생성 AI에 대한 투자를 지속할 것임을 예고했습니다. 천문학적인 금액이 쏟아지고 있는 만큼, 생성 AI 산업을 구성하는 트렌드는 빠른 속도로 변화하고 있는데요. 이번 글에서는 지난 8월 안드레센 호로위츠가 발표한 자료를 토대로 사용자들이 실제 어떤 생성 AI 서비스를 사용하고 있는지, 소비 트렌드를 살펴보고자 합니다.
- 코드 작성 시간 절반으로 줄여줄 5가지 개발 툴 | 요즘IT
- 여러분은 매일 코드 작성과 디버깅에 얼마나 많은 시간을 소비하나요? 지금부터 소개해 드릴 AI와 자동화 툴 5가지만 제대로 활용해도 그 시간을 절반으로 줄일 수 있습니다. 개발자의 하루는 해결해야 할 문제로 가득하니까요. 코드 작성을 도와주는 GitHub Copilot부터 코드 품질을 한눈에 개선해 주는 SonarQube까지. 이 툴들은 어떻게 여러분의 개발 생산성과 코드 품질을 끌어올려 줄까요?
İyi Bir Geliştirici Olmak İçin Uygulanması Gereken 10 Alışkanlık
>> telematik / küme platformu oluştururken ve sürdürürken hissettiklerim, ancak uygulamayı düzgün bir şekilde yapamadığım şeyler. Değişimden korkmamalı ve burada olduğu gibi küçük parçalara bölüp uygulamaya koyarsak mümkün olabilir.
1. ""Bu kadar küçük yapmaya gerek var mı?"" diye düşüneceğiniz kadar küçük commit'ler yapın.
Belirli bir değişikliği geri almanız gerekebileceğindendir. 6 gün önce oluşan bir hatanın tam yerini biliyor olmak ve karmaşık birleştirme çakışmaları olmadan sadece ilgili commit'i geri alabilmek büyük bir rahatlama sağlar. Benim kriterim basittir; derlenen kod commit edilebilir.
2. Kent Beck'in özdeyişini uygulayın: "İstediğiniz değişiklik için önce o değişikliği kolaylaştırın (dikkat: bu zor olabilir), sonra kolaylaştırılan değişikliği yapın."
"İstediğiniz değişiklik için önce o değişikliği kolaylaştırın (dikkat: bu zor olabilir), sonra kolaylaştırılan değişikliği yapın."
Tüm commit'lerin yarısından fazlasının yeniden düzenleme olması için çaba gösterin. Sürekli yeniden düzenleme, 10 dakika içinde yapılabilecek iyileştirmeleri bulup uygulamak anlamına gelir. Bu küçük iyileştirmeler sayesinde daha sonra büyük istekler geldiğinde basit değişikliklerle çözüm bulunabilir. Büyük çaplı yeniden düzenlemelerden kaçınılmalıdır.
3. Tüm kod borçtur.
Yayınlanmamış kod, borçların borcudur. Kodun düzgün çalışıp çalışmadığını, en azından diğer işlevleri bozup bozmadığını kontrol etmelisiniz. Testler güven verir, üretim dağıtımı doğrulama sağlar. Sık sık dağıtım yaparak barındırma maliyeti biraz artabilir, ancak son işin gerçek bir ilerleme olduğunu doğrulayabilmek açısından yeterince değerlidir. Agile ilkelerinden biri "çalışan yazılım ilerlemenin ana ölçütüdür" der. Burada "çalışan" ve "ilerleme" kelimeleri kilit bir anlam taşıdığı için, kendi tanımımı yaptım. "Çalışan", dağıtılabilir seviye anlamına gelir ve herhangi bir işlevliğe katkıda bulunan kod "ilerlemedir".
4. Çerçeve özelliklerini test ediyor musunuz? Eğer öyleyse, yapmayın.
Çerçeveler zaten sizden çok daha uzman kişiler tarafından test edilmiştir ve useState() hook'unun amaçlandığı gibi çalışacağına güvenmelisiniz. Bileşenleri küçük tutmak, çerçevelerin temel işlerin çoğunu halletmesini sağlayacağından, çok fazla teste gerek yoktur. Bileşenler büyüdükçe karmaşıklık artar ve o kadar çok test yazmanız gerekir.
5. Belirli bir fonksiyon hiçbir yere uymuyorsa, yeni bir modül (veya sınıf veya bileşen) oluşturun ve daha sonra uygun bir yer bulun.
Uymadığını hissettiğiniz yere zorla yerleştirmektense, yeni bir bağımsız yapı oluşturmak daha iyidir. En kötü durumda bile bağımsız bir modül olarak kalması o kadar da kötü değildir.
6. API'nin nasıl olması gerektiğini bilmiyorsanız, önce testi yazın.
Bu, bu durumda kendiniz olan "müşteri" bakış açısından düşünmenizi sağlar. Önce kodu yazıp daha sonra test etmiş olsaydınız bulamayacağınız durumları ortaya çıkarabilirsiniz. TDD'ye çok dogmatik olmak gerekmez ve daha büyük birimlerle çalışmak da sorun değildir (örneğin: test geçmeden önce birkaç satır kod yazmak). Başarısız kod miktarının her zaman az olması gerekmez. Ne yaptığınızı biliyorsanız, prensiplerin verimliliğinizi engellemesine izin vermeyin.
7. Kopyala-yapıştır bir kereye kadardır.
İkinci çoğaltmayı (yani üçüncü kopyalamayı) yapmayın. Bu noktada iyi bir soyutlama oluşturabilecek yeterli örnek olacaktır. Aynı işlevlerin uygulamalarının birbirinden farklı olma riski çok yüksektir, bu nedenle entegrasyon gereklidir. Benzer işlevleri birçok kez uygulamak yerine biraz garip parametrelendirme daha iyidir. Bu durum tekrar yaşanırsa, dört farklı uygulamayı entegre etmektense parametreleri geliştirmek daha kolay olacaktır.
8. Tasarım eskir.
Yeniden düzenleme ile hızını yavaşlatabilirsiniz, ancak sonunda çalışma biçimini değiştirmeniz gerekir. Eskiden kıymetli bulup gurur duyduğunuz şeyleri atmanız gerektiğinde çok üzülmeyin. O zamanlar elinizden gelenin en iyisini yaptınız ve değiştirmeye gerek kalmayacak kadar mükemmel yapmadığınız için kendinizi suçlamanıza gerek yok. Yazılım geliştirmenin büyük bir kısmı yazılımı değiştirmektir. Bunu kabul edin ve ilerleyin. Mükemmel bir tasarım yoktur ve değişiklik yazılım geliştirmenin özüdür. Ne kadar becerikli bir şekilde değişiklik yapabildiğiniz, geliştirici olarak yeteneğinizi belirler.
9. Teknoloji borcu üç kategoriye ayrılabilir:
1) Mevcut çalışmayı engelleyen şeyler, 2) Gelecekteki çalışmayı engelleyen şeyler, 3) Gelecekteki çalışmayı engelleyebilecek şeyler. Diğer tüm sınıflandırmalar bu üçünün alt kümesidir. #1'e ait olanları en aza indirin ve #2'ye odaklanın. #3'ü takmayın.
10. Test edilebilirlik, iyi bir tasarımla yakından ilgilidir.
Kolayca test edilememesi, tasarımın değiştirilmesi gerektiğine dair bir işarettir. Bazen bu tasarım, test tasarımı olabilir. Örneğin, em.getRepository(User).findOneOrFail({id})'yi taklit etmenin zor olması, bu çağrıyı taklit edilebilir ayrı bir fonksiyona ayırmanız veya varlık yöneticisi yöntemlerini kolayca taklit edebilen bir test yardımcı programı yazmanız gerektiği anlamına gelir. Testlerin yazılmamasının nedeni test etmek istememek değil, test etmenin zor olmasıdır.
Yorumlar0