Flink gibi dağıtık sistemlerde HA’yi korumak için 2~3 rack bulundurmak gerekir; ancak Kubernetes entegrasyonuyla bunun sağlandığı anlaşılıyor. Yine de sonuçta kube slave node tarafındaki kaynakları da düşünmek gerekecek; acaba sadece Flink çalıştıran node’lardan oluşan bir yapı mı kurdular diye düşündürüyor (Flink yükü sırasında slave node’ların düşmesi gibi bir sorun olabilir).
Bu açıdan bakınca Kubernetes kullanmanın bir avantajı var mı?
Ayrıca Flink’te window function kullanıldığında, o aralıktaki veri bellekte tutulurken SQL join ifadesi çalışıyor; bu trade-off açısından bakıldığında Flink gerçekten iyi bir tercih mi diye düşünüyorum. Zaman geçtikçe büyüyen SQL + job öldüğünde ortaya çıkacak büyük sorunlar...
Ben de en üst seviyedeki data source tarafında join gereken durumlarda Flink kullanmadan, bunu application level’a indirip hangi yöntemle işleyebileceğimizi düşünüyorum.
Her şey güzel ama Kore'den satın almak için yurt dışında yaşayan tanıdık birine ihtiyaç duymanız gibi çok büyük bir dezavantajı var...
Bir de yönlendirme depolarını oldukça sıkı şekilde engellediklerini duydum
Güzel yazı için teşekkürler. AWS’de oluşturulan dosyaları (rapor gibi) HWP olarak üretmek istiyorum ancak ilgili referansların az olması nedeniyle zorlanıyorum. Şu anda Word kullanıyoruz. Eğer bu konuda faydalı olabilecek kaynaklar varsa, link paylaşmanızı rica ederim.
MS Word veya LibreOffice ile kıyaslandığında, Hangeul ile istediğim biçimde belgeler oluşturmak benim için çok daha rahattı. Dağıtım da zaten PDF olarak yapılabiliyor.
Elbette, Hangeul'e alışkın olduğum için bana böyle geliyor olabilir.
Daha önce duyduğuma göre hwpx, hwp’nin ikili biçiminin basitçe XML olarak açılıp ardından ZIP ile paketlenmiş haliymiş.
Yine de en azından okunabiliyor...
Kodlama odaklı kişisel gelişim kitaplarının, teknolojiye ya da uygulama yöntemlerine dair henüz bir değer yargısı oluşmamış başlangıç seviyesindeki kişiler için faydalı olduğunu, ancak deneyim arttıkça yararının azaldığını düşünüyorum. Çünkü her projeye ve ortama uyan mutlak doğrular yok; ayrıca genel geçer yaklaşımların işlemediği durumlar da var. Diğer genel kişisel gelişim kitaplarındaki tavsiyelerde olduğu gibi, bunlara da belli bir mesafeyle yaklaşarak yalnızca duruma uyan önerileri uygulamak ve tavsiyelerin peşinden körü körüne gitmemek daha doğru görünüyor.
Flink gibi dağıtık sistemlerde HA’yi korumak için 2~3 rack bulundurmak gerekir; ancak Kubernetes entegrasyonuyla bunun sağlandığı anlaşılıyor. Yine de sonuçta kube slave node tarafındaki kaynakları da düşünmek gerekecek; acaba sadece Flink çalıştıran node’lardan oluşan bir yapı mı kurdular diye düşündürüyor (Flink yükü sırasında slave node’ların düşmesi gibi bir sorun olabilir).
Bu açıdan bakınca Kubernetes kullanmanın bir avantajı var mı?
Ayrıca Flink’te window function kullanıldığında, o aralıktaki veri bellekte tutulurken SQL
joinifadesi çalışıyor; bu trade-off açısından bakıldığında Flink gerçekten iyi bir tercih mi diye düşünüyorum. Zaman geçtikçe büyüyen SQL + job öldüğünde ortaya çıkacak büyük sorunlar...Ben de en üst seviyedeki data source tarafında join gereken durumlarda Flink kullanmadan, bunu application level’a indirip hangi yöntemle işleyebileceğimizi düşünüyorum.
Harika bir tartışma.
Ben de düşününce, junior'lara John'un philosophy of sw design kitabını öneriyorum ama Clean Code'u pek önermemişim.
Orijinal yazı silinmiş görünüyor. Web arşivinden bakın.
https://web.archive.org/web/20250225151227/…
Vay, az önce PR incelemesi yapan GitHub uygulamasını etkinleştirdim. Nasıl olacağını merak ediyorum.
Her şey güzel ama Kore'den satın almak için yurt dışında yaşayan tanıdık birine ihtiyaç duymanız gibi çok büyük bir dezavantajı var...
Bir de yönlendirme depolarını oldukça sıkı şekilde engellediklerini duydum
Bunun doğrudan
docx'i takip ederek yapıldığını söylüyorlar.Zaten MS de
doc'tandocx'e geçerken bunu yapmıştı.Ne olursa olsun, yalnızca başlıklara körü körüne uymak yerine bağlamı iyi anlayıp uygulamanın önemli olduğunu düşünüyorum.
Hm... TS'den daha tip güvenli bir geliştirme olup olmayacağını merak ediyorum.
2021-02 Modüler dizüstü bilgisayar Framework Laptop tanıtıldı
2021-07 Framework Laptop sevkiyatları başladı ve incelemeler yayımlandı
2021-10 Modüler dizüstü bilgisayar Framework için Marketplace duyuruldu
2022-01 Modüler dizüstü bilgisayar Framework, firmware'i açık kaynak olarak yayımladı
2022-05 Yeni yükseltmelerle gelen Framework Laptop duyuruldu
2022-09 Modüler dizüstü bilgisayar Framework, Google ile birlikte Chromebook sürümünü duyurdu
2024-01 Framework Laptop 16 incelemesi
Hım, Chromebook'u bile yükseltilebilir hâle getirdiler ama asıl masaüstünde yükseltme seçenekleri epey sınırlı görünüyor.
Bence de Hangeul 97 çıkana kadar mükemmel bir yazılımdı.
Güzel yazı için teşekkürler. AWS’de oluşturulan dosyaları (rapor gibi) HWP olarak üretmek istiyorum ancak ilgili referansların az olması nedeniyle zorlanıyorum. Şu anda Word kullanıyoruz. Eğer bu konuda faydalı olabilecek kaynaklar varsa, link paylaşmanızı rica ederim.
Bence yapay zekanın eğitimi doğrudan PDF’e odaklansa ve Hangul için de iyi bir PDF dönüştürücü yapılsa daha iyi olmaz mı? haha
MS Word veya LibreOffice ile kıyaslandığında, Hangeul ile istediğim biçimde belgeler oluşturmak benim için çok daha rahattı. Dağıtım da zaten PDF olarak yapılabiliyor.
Elbette, Hangeul'e alışkın olduğum için bana böyle geliyor olabilir.
Daha önce duyduğuma göre hwpx, hwp’nin ikili biçiminin basitçe XML olarak açılıp ardından ZIP ile paketlenmiş haliymiş.
Yine de en azından okunabiliyor...
Han/geul belge dosya biçimi: HWP biçim yapısına göz atma
Kodlama odaklı kişisel gelişim kitaplarının, teknolojiye ya da uygulama yöntemlerine dair henüz bir değer yargısı oluşmamış başlangıç seviyesindeki kişiler için faydalı olduğunu, ancak deneyim arttıkça yararının azaldığını düşünüyorum. Çünkü her projeye ve ortama uyan mutlak doğrular yok; ayrıca genel geçer yaklaşımların işlemediği durumlar da var. Diğer genel kişisel gelişim kitaplarındaki tavsiyelerde olduğu gibi, bunlara da belli bir mesafeyle yaklaşarak yalnızca duruma uyan önerileri uygulamak ve tavsiyelerin peşinden körü körüne gitmemek daha doğru görünüyor.
Temiz kodun amaç değil, bir araç olduğunu unutmamak gerekir.
Düşündüğümden daha etkili bir yaklaşım, Go tabanlı frontend geliştirmek. Kullanım alanlarının artmasının bir nedeni varmış.
Git çekirdek geliştiricileri Git'i nasıl yapılandırıyor ve kullanıyor?