Principled Coder
Linux işletim sisteminin temelini atan Linus Torvalds, bunu 28 yıl önce mütevazi bir e-posta ile “comp.os.minix” kullanıcı grubuna duyurdu.
Diğer programcılara bir e-posta göndererek ve yardımlarını istedi. O zamanlar, Linux’u GNU gibi büyük veya profesyonel olmayacak bir hobi projesi olarak tanımladı. Orijinal mail buradan ulaşarak okuyabilirsiniz.
Basit bir proje olarak başlatılan Linux projesi, bugün bilişim dünyasını çok önemli noktalara taşımıştır.
Bir sonraki yazıda görüşmek dileğiyle.
Angular 6 ve sonrası sürümlerde Angular CLI workspace birimleri sayesinde geliştiricilere bir çalışma alanında birden fazla projede oluşturma imkanı sağlanmıştır. Bu bize birçok proje ve kütüphaneyi aynı çalışma ortamında barıdırma olanağı sunmuştur. Artık büyük uygulamaları küçük modüllere veya küçük uygulamalara bölerek geliştirme özgürlüğüne kavuşmuş oluyoruz. Örneğin ortak bir kullanıcı doğrulama modülünü diğer uygulamalara aktararak tekrar kullanabilme yeteneği kazandırabiliriz. Tekrar kullanılabilir modüller sayesinde kod tekrarları azaltılarak iş akışı kolaylaştırlabilmektedir.
Angular projelerinde kod tekrarlarını engellemek ve tekrar kullanılabilirliği arttırabilmek için modüller veya kütüphaneler kullanılabilir. Angular modüller ve kütüphaneler arasında nasıl bir fark olduğu merak konusudur.
Bir projenin içinde bulunan uygulama bileşenlerini (Components) bir araya getirir. Modüller tüm bileşenlerini kendi kök dizininde barındırır. Bu sayede modül, kullanılmak üzere ihtiyaç duyulan yere aktarılabilir. Bu sayede modülün kullanıldığı uygulamanın modülün içinde olan biten süreci bilmesine gerek kalmaz.
Proje modüllerinin bir çok projede kullanılma ihtiyacı bulunan şirketlerde, modül dizinlerinin projeden projeye taşınması biraz zahmetli olabilir. Ayrıca taşınan modülde yapılan değişikliğin tüm projelere tekrardan dağıtılması zor bir süreçtir. Geliştiricilerin birbirinden uzak ortamlarda bulunduğunda işler biraz karışabilir. Bu durumda modüllerin bir kütüphane haline getirilerek paketlenmesi gerekmektedir. Paketlenen modüllerin versiyonlanması ve npm gibi ortamlarda dağıtılması ile tekrar kullanılabilir kütüphanelerin dağıtımı sağlanmış olur.
Tek başına projeler geliştirenler için modüllerin taşınarak kullanılması daha uygun bir çözüm olabilir. Ancak şirket ortamlarında veya açık kaynak olarak dağıtılacak projelerde kütüphanelerin oluşturulması daha doğru bir yöntem olarak görülmektedir.
Bir sonraki yazıda görüşmek dileğiyle.
NuGet üzerinden paket yayınlamak istediğinizde, nuget.org üzerinden bir hesap oluşturmalı ve profil hesabınıza girerek bir “API key” yani anahtar oluşturmalısınız.
Ancak oluşturulan bazı API anahtarları ASCII harici karakterler içermektedir. Örneğin:
Yukarıdaki anahtarlarda Türkçe “ı” karakteri bulunmaktadır.
Bu anahtarlardan birini kullanarak bir paket yayını yapmak için gerekli komutu aşağıdaki gibi çalıştırdığımda:
dotnet nuget delete MyPack 1.0.1 -s https://api.nuget.org/v3/index.json -k apikey
Karşıma bir uyarı geldi.
Request headers must contain only ASCII characters.
Komutu bir kaç kez çalıştırıp, sorunu düşünürken aklıma anahtarı yenilemek gibi bir çözüm geldi. Bir kaç denemeden sonra nuget.org bana sadece ASCII karakterlerden oluşan bir API key oluşturmayı başardı. Bu anahtarı denediğimde komut başarılı bir şekilde çalıştı.
Konu ile ilgili GitHub üzerinden bir sorun(issue) bildiriminde bulundum. Sorun bildirim bağlantısı: https://github.com/NuGet/Home/issues/9385
Konu ile ilgili henüz bir geri bildirim almadım ancak işleme alındığını zannediyorum. Aynı sorunu yaşayanlar olursa, durum özetle bu şekildedir.
Bir sonraki yazıda görüşmek dileğiyle.
Nuget paket yöneticisi üzerinde kendi paketimi yayınlarken bir sorun farkettim ve GitHub üzerinden bir sorun(issue) bildirimi yapma ihtiyacı duydum. Bildirim bağlantısı:https://github.com/NuGet/Home/issues/9386
Sorun özetle şu şekildedir:
Windows 10 Home edition Türkçe sürümü üzerinden NuGet version (5.4.0.2) ile bir “delete” komutu çalıştırdığımda aşağıdaki gibi bir kabul uyarısı ekrana gelmiştir. Komutun “delete” vaya başka bir komut olması önemli değildir. Sunucuya bir talep gönderim komutu olması yeterlidir.
Uyarıda devam edip etmeme konusunda bir uyarı mesajı sunuluyor ve Y/N şeklinde komut bekleniyor. Ancak N komutu yazılınca, yani hayır devam etmek istemiyorum denildiğinde komut çalıştırılıyor Y komutu yazılınca yani evet devam etmek istiyorum denildiğinde işlem iptal ediliyordu.
Bu sorunun bir tercüme sorunu veya bir mantıksal sorun olduğu hususunda bir bildirimde bulundum. GitHub üzerinden heng-liu, sorunun bir tercüme sorunu olabileceği şeklinde bir cevap vermiştir.
Konu ile ilgili aynı sorunu yaşayanlar olursa, durum özetle bu şekildedir.
Bir sonraki yazıda görüşmek dileğiyle.
Entity Framework Core 2.0 ve sonrası versiyonlar ile birlikte, veritabanı sorgulamalarda DbContext üzerinden yapılan model harici sql sorgulamaları kaldırılmıştır.
Mevcut durumda, Entity Framework üzerinden raw sql sorgulamalarını yapmak için genellikle bir model sınıfı tanımlanmalıdır. Yapılan sql sorguları, tanımlanan bu modele cast edilerek çalıştırılabilmektedir.
var result = context.Product.FromSql("SELECT * FROM PRODUCTS").ToList();
var result = await context.Product.FromSql("SELECT * FROM PRODUCTS").ToListAsync();
Ancak bu durum, raporlama işlemleri gibi karmaşık sorguların bulunduğu sql sorgularının mevcut entity framework nesnelerinden yapmak istediğimizde önümüze engel çıkarmaktadır. Üç veya dört tabloyu join ederek sorgulmalar yapmak isteyebiliriz. Ya da modelimiz dışında tablolardan raporlar çekmek isteyebiliriz.
Entity Framework Core ile çalışırken, raw sql komutlarının çalıştırılabildiği B3.Extensions.Data kütüphanesi GitHub üzerinden yayına açılmıştır. Örnek kullanımı aşağıdaki şekildedir:
public async Task<IActionResult> Get()
{
var sql = "SELECT type, SUM(length) FROM ways GROUP BY type";
var queryResult = await _context.ExecuteQueryAsync(sql);
return Ok(response);
}
Kütüphaneye NuGet üzerinden de ulaşabilirsiniz. Umarım kullanıcıların işlerini kolaylaştırır.
Bir sonraki yazıda görüşebilmek dileğiyle.