Ubuntu yeni kullanıcı ekleme işlemleri

12 May

Ubuntu ortamında kullanılan “sudo” komutu, “super user do” anlamına gelmektedir. Yani sudo komutunu kullanmak için yönetici yetkilerine sahip olmak gerekmektedir. Bir kullanıcının super user olması için “sudo” grubuna dahil olması gerekmektedir. Öncelikle bir kullanıcı oluşturulması gerekmektedir.

1. Giriş

sudo yetkili kullanıcıların oluşturulabilmesi için öncelikle root kullanıcısı ile ya da root yetkili bir kullanıcı ile giriş yapmak gerekmektedir.

ssh root@server_ip_address

2. Kullanıcı hesabı oluştur

Yeni kullanıcı oluşturmak için adduser ve useradd komutları kullanılır.

useradd ve adduser komutları arasında ne fark var?

useradd , aslında sistemle derlenmiş yerel bir binary dosyadır. adduser ise arka tarafta useradd binary dosyasını kullanan bir perl script’tir.

2.1  adduser komutu ile kullanıcı ekle

Yeni kullanıcı oluşturma işlemi adduser komutu ile yapılmaktadır. Örneğin bucuncu adında bir kullanıcı oluşturmak için gerekli komut aşağıdaki şekildedir.

adduser bucuncu

Komut çalıştırıldığında aşağıdaki işlemler gerçekleştirilerek kullanıcı hesabı ve dosyaları oluşturulur.

root@localhost:~# adduser bucuncuAdding user `bucuncu’ …
Adding new group `bucuncu’ (1001) …
Adding new user `bucuncu’ (1001) with group `bucuncu’ …
Creating home directory `/home/bucuncu’ …
Copying files from `/etc/skel’ …
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
Changing the user information for bucuncu
Enter the new value, or press ENTER for the default
Full Name []:
Room Number []:
Work Phone []:
Home Phone []:
Other []:
Is the information correct? [Y/n] y

Parolayı girdikten sonra, kullanıcı için otomatik olarak bir giriş dizini oluşturur, giriş dizinindeki birkaç yapılandırma dosyasını kopyalar ve yeni kullanıcının bilgilerini ayarlamanız istenir. Tüm bu bilgileri boş bırakmak istiyorsanız, varsayılanları kabul etmek için ENTER tuşuna basmanız yeterlidir..

adduser komutu, kullanıcı hesabının otomatik bir şekilde oluşturan, kullanıcı dostu bir komuttur.

2.2 useradd komutu ile kullanıcı ekleme

useradd komutu, parametreler kullanarak kullanıcı oluşturma işlemi için kullanılan komuttur.

useradd bucuncu -m -s /bin/bash -g users -G dbusers

Bu komut ile kullanıcı oluşturulurken, kullanıcı için gerekli olan tüm parametreler elle girilmelidir.

  • -m parametresi: –create-home anlamına gelir ve eğer daha önce oluşturulmamış ise home/bucuncu dizinini oluşturur.
  • -s parametresi: –shell anlamına gelir. Kullanıcının shell de oturum açması için gereklidir. Bu paramtreyi kullanmadan bir kullanıcı oluşturursanız, /etc/passwd içerisinde kullanıcıyı bucuncu:x:1000:1000::/home/bucuncu:/bin/sh şeklinde bulunur. Bu şekilde oturum açtığınızda terminalde yalnızca $: şeklinde bir terim görürsünüz. Eğer bu parametreyi kullanırsanız, /etc/passwd içerisinde kullanıcıyı bucuncu:x:1000:1000::/home/bucuncu:/bin/bash şeklinde görebilirsiniz. Bu şekilde oturum açtığınızda terminalde komut satırını bucuncu@localhost:~# şeklinde görebilirsiniz.
  • -g parametresi: –gid anlamınag elir. Yani grup id olarak adlandırılabilir.
  • -G parametresi: –groups anlamına gelir. Kullanıcıyı birden çok gruba eklemek için gereklidir.

useradd komutu için gerekli bütün parametrelere buradan ulaşabilirsiniz.

3. Kullanıcıyı sudo grubuna ekle

Ubuntu sistemlerinde varsayılan olarak, sudo grubunun üyelerine sudo erişim yetkisi verilir. sudo grubunda olmayan kullanıcılar sudo komutunu kullanamazlar. Çünkü sudo komutu yönetici yetkilerine sahip işlemler için gereklidir.Oluşturulan kullanıcıyı sudo grubuna eklemek için usermod komutu kullanılır.

usermod -aG sudo bucuncu

4. Yeni kullanıcı ile giriş yap

Oluşturulan yeni kullanıcı ile giriş yapmak için gerekli komut aşağıdaki şekildedir.

ssh bucuncu@localhost

5. Kullanıcı şifresini değiştir

Kullanıcı şifresini değiştirmek için:

sudo passwd bucuncu

komutu kullanılabilir. Komut çalıştığında iki defa yeni şifre girmeniz istenir.

Sonuç

Sudo yetkilerine sahip bir kullanıcı oluşturmayı görmüş olduk. Bu işlemi gerçekleştirirken  useradd ve adduser komutlarının kullanılabileceğini ve bu komutlar arasındaki farkları öğrenmiş olduk. Artık bu kullanıcı hesabıyla Ubuntu sunucunuza giriş yapabilir ve yönetici komutlarını çalıştırmak için sudo komutunu kullanabilirsiniz.

GitBash angular build base-href sorunu

5 May

Angular projelerini production ortamına almak için “ng build –prod” komutu kullanılır.

ng build –prod

Bu komutu kullandığımızda üretilen index.html dosyasında bir base href etiketi oluşturulur.

<base href=”/”>

Eğer proje IIS gibi bir http server üzerindeki ana web site dizinden yayınlanıyorsa doğrudan çalışacaktır. Ancak site, ana web site altında bir alt klasörde çalışacak ise, (örneğin “Default Web Site/my-app”) base href etiketi, angular build işlemi sırasında belirlenebilmektedir. Bu durumda çalıştırılan komut şu şekilde olacaktır. (angular deployment)

ng build –base-href /my-app/ –prod

Bu durumda GitBash konsolunun index.html içerisinde oluşturduğu base href parametresi şu şekilde olmaktadır:

<base href=”C:/Program Files/Git/my-app”>

Bu sorun angular cli ile alakalı bir sorun değil, git bash ile alakalı bir sorundur. Bu sorunu gidermek için kullanılacak olan angular komutu aşağıdaki gibi olmalıdır:

ng build –base-href=”//my-app\\” –prod

 

Linus Torvalds’ın Meşhur E-posta’sı

24 Nis

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 CLI Workspace Birimleri Module vs Library

23 Nis

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.

Modüller (Module)

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.

Kütüphaneler (Library)

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 Http Request ASCII Character Bug

22 Nis

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:

  • oı2jr55h73me2l3yptvakped55nrsbcebpfj6jsrjkpn3m
  • ıy2jr55h73me2l3yptvakped55nrsbcebpfj6jsrjkpn3m

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 Acceptance Command Bug

21 Nis

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 Extensions Kütüphanesi B3.Extensions.Data Yayında

20 Nis

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.

Coğrafi ve Projeksiyon Koordinat Sistemleri

16 Mar

Coğrafi Koordinat Sistemleri

Bir coğrafi koordinat sistemi, (CKS) yeryüzündeki konumları tanımlamak için üç boyutlu küresel bir yüzey kullanır. CKS’ne genellikle datum şeklinde yanlış adlandırılır. Datum, CKS’nin yalnızca bir parçasıdır. Çünkü bir CKS, açısal bir ölçü birimi, bir ana meridyen ve bir datum içerir.

CKS’de bir nokta, boylam ve enlem değerleri ile belirtilir. Boylam ve enlem, dünyanın merkezinden dünyanın yüzeyinde bir noktaya kadar ölçülen açılardır. Bu açılar genellikle derece cinsinden ölçülür. Aşağıdaki şekil buna bir örnektir.

Küresel sistemde, yatay çizgiler veya doğu-batı çizgileri eşit aralıklı enlem veya paralel çizgilerdir. Dikey çizgiler veya kuzey-güney hatları eşit boylam çizgileri veya meridyenlerdir. Bu çizgilerin kesişimi dünyayı kaplar ve retükül adı verilen ızgaralı bir ağ oluşturur.

Sıfır enlem çizgisine ekvator, sıfır boylam çizgisine ana meridyen denir. Coğrafi koordinat sistemlerinin çoğunda, ana meridyen İngiltere’nin Greenwich kentinden geçen boylamdır. Diğer ülkeler ise Bern, Bogota ve Paris’ten geçen boylam çizgilerini ana meridyen olarak kullanırlar. CKS’de (0,0) yani orijin, ana meridyen ve ekvatorun kesiştiği nokta olarak tanımlanır.

CKS’de enlem ve boylam değerleri geleneksel olarak ondalık derece veya derece, dakika ve saniye (DMS) olarak ölçülür. Enlem değerleri ekvatora göre ölçülür ve Güney Kutbunda -90 ° ile Kuzey Kutbunda + 90 ° arasında değişir. Boylam değerleri, ana meridyene göre ölçülür. Batı yönünde seyahat ederken -180 ° ile doğu yönünde seyahat ederken 180 ° arasındadır.

Boylam değerlerini X ve enlem değerlerini Y ile eşitlemek yararlı olabilir. Coğrafi koordinat sisteminde tanımlanan veriler bir derece doğrusal bir ölçü birimi gibi görüntülenir. Bu yöntem temelde Plate Carrée projeksiyonu ile aynıdır.

Enlemlerin kutuplara doğru gittikçe boyları küçülür ve kutuplarda sıfır olur.  Enlem ve boylam derecelerinin standart bir uzunluğu olmadığından, mesafeleri veya alanları doğru bir şekilde ölçemez veya verileri düz bir haritada veya bilgisayar ekranında kolayca görüntüleyemezsiniz.

Projeksiyon Koordinat Sistemleri

Projeksiyon kelimesi yansıtma anlamına gelmektedir. Projeksiyon koordinat sistemi düz, iki boyutlu bir yüzey üzerinde tanımlanır. Coğrafi bir koordinat sisteminden farklı olarak, projeksiyon koordinat sisteminin sabit uzunlukları, açıları ve iki boyuttaki alanları vardır. Bir projeksiyon koordinat sistemi, her zaman bir küre veya küreye dayanan bir coğrafi koordinat sistemini temel alır. Yani küresel yer yüzünün, düz bir zemine yansıtılmış halidir.

Bir projeksiyon koordinat sisteminde, konumlar bir ızgara üzerinde x, y koordinatları ile belirlenir ve orijin merkezde bulunur. Her konumun, bu merkezi konuma referans veren iki değeri vardır. Biri yatay konumunu diğeri dikey konumunu belirtir. Bu iki değere x ve y koordinatı denir. Başlangıçtaki koordinatlar x = 0 ve y = 0’dır.

Eşit aralıklı yatay ve dikey çizgilerin oluşturduğu ızgaralı yapıda, merkezdeki yatay çizgiye x ekseni, orta dikey çizgiye y ekseni denir. Birimler tutarlıdır ve tüm x ve y aralıkları arasında eşit aralıklıdır. Başlangıç noktasının üzerindeki yatay çizgiler ve başlangıç noktasının sağındaki dikey çizgiler pozitif değerlere sahiptir; aşağıdaki veya soldaki negatif değerlere sahiptir. Dört çeyrek daire, pozitif ve negatif X ve Y koordinatlarının dört olası kombinasyonunu temsil eder.

Sonuç

Projeksiyon ve Coğrafi koordinat sistemleri birbirlerinin dönüşümüdür. Coğrafi koordinat sistemi küresel yer yüzünü temsil ederken, projeksiyon koordinat sistemi, küresel yapının düz bir kağıt üzerine yansıtılmış halidir.

Kaynaklar

  • http://resources.arcgis.com/en/help/main/10.1/index.html#//003r00000006000000
  • https://blogs.esri.com/esri/arcgis/2010/08/12/wgs84-vs-nad83/
  • http://resources.arcgis.com/en/help/main/10.1/index.html#/What_are_projected_coordinate_systems/003r0000000p000000/
  • https://communityhub.esriuk.com/geoxchange/2012/3/26/coordinate-systems-and-projections-for-beginners.html

C# Exception Yapısı ve Custom Exception

5 Şub

Yazılım geliştirici olarak yazdığımız kodlarda oluşabilecek istenmeyen durumlar ile başa çıkmak durumundayız. Aksi taktirde yazılımlarımız zamanla kullanılamaz hale gelebilir. İstisnai durumların oluşturulması veya oluşturulmaması üzerine zamanla bazı fikirler gelişmiştir.

Microsoft tarafından oluşturulan eski yönergelerde istisnai durumlar ile başaçıkabilmek için bazı yönlendirmeler bulunmaktadır. Bunlardan biri de temel Exception sınıfından türetilmiş SystemException ve ApplicationException şeklinde iki kategori oluşturarak istisnai durumları gruplamaya çalışmaktır.

ApplicationException

ApplicationException sınıfı System.Exception sınıfından türetilmiş bir istisnai durum bildirim türüdür. Bu türü, uygulamamızın iç yapısı ile alakalı istisnai durumlar oluştuğunda bildirimler oluşturmak amacıyla oluşturulmuştur. İstisnai durumlar bir hata veya bir uyarı olabilir. Uygulamamıza özel istisnai durum sınıflarına ihtiyaç duyduğumuzda ApplicationException sınıfından durumumuza özel yeni bir sınıf türetebiliriz. Özel istisna (custom exception) sınıfları oluşturma konusunda Microsoft tarafından oluşturulan kılavuzlarda tecrübe aktarımları mevcuttur.

SystemException

SystemException sınıfı da System.Exception sınıfından türetilmiştir. .Net Framework üzerinde CLR tarafından üretilen tüm istisnalar bu sınıf altında toparlanmıştır. Bu sınıf ile sisteme ait istisnai durum bildirimleri oluşturulmaktadır ve fetal error diye adlandırılan önemli hataların oluştuğu istisnai durumlarda kullanılırlar. Örneğin veritabanı bağlantı hataları, dosya hataları, bellek kullanım hataları oluştuğu durumlarda SystemException sınıfından türetilmiş olan sınıflar kullanılır.

İstisnai durumların kod ile ayırımı

Kodlama sırasında try-catch bloğunda istisnai durumun türüne göre tavrımızı belirleyebiliriz.

   try{
       var data = fileService.ReadFromFile();
   }
   catch(ApplciationException e){
       // Bu kısımdaki hata kontrolüm altında devam et...
   }
   catch(SystemException e){
       // Bu hata sistemsel bir sorundur log tut ve tekrar istisna gönder
       throw;
   }

SystemException türünde bir durum meydana geldiyse bu hatalar mutlaka log servisleri ile kayıt altına alınmalıdır ve görmezden gelinmemelidir.

Runtime esnasında oluşan hataları System, uygulama tarafında oluşan istisnaları Application olarak ayırmak mantıklı gibi görünebilir. Ancak bir istisnanın ölümcül(fetal) olarak değerlendirilmesi istisnanın içinde bulunduğu şartlara bağlıdır. Çalışma zamanında oluşan her hatanın ölümcül(fetal) olduğu söylenemeyeceği gibi framework dışındaki geliştiricilerin yazdığı uygulama istisnaların hepsinin göz ardı edilebilir olduğu söylenemez.

Örneğin FileNotFoundException durumu oluştuğunda her zaman programı kapatmanın anlamı yoktur. Bu durum kullanıcıya uygun bir mesaj ile iletilebilir. Hatta bazı dosyaların eksikliğinin öngörülebilmesi için faydalıdır bile denilebilir.

Bu nedenle bu başlangıç kılavuzu çıkmadı ve Microsoft da zaten çıkarmak için zorlamadı. Öte yandan şu anda .Net Framework’te bile ApplciaitonException sınıfından türetilmiş birkaç istisna bulabilirsiniz. Günümüzde yeni bir istisna türü oluşturmak isteyen biri bu iki kategoriyi kullanmak yerine Exception temel sınıfından yeni bir istisna sınıfı oluşturmaktadır. Yani System ve Application kategorisini kullanan pek yoktur.

Özel istisna türleri (custom exceptions) oluşturmak

Exception durumları hakkında kısa bir zaman yolculuğu yaptıktan sonra asıl konumuz olan özel istisna sınıflarının oluşturulmasına gelmiş bulunuyoruz.

Günümüzde geliştiricilerin kendine özel istisna türlerini oluşturmak için belli bir hiyerarşi oluşturduğunu görmek mümkündür. Örneğin:

Burada iş kurallarına ait tüm istisnalar BusinessRuleException altında toplanmıştır.

Peki bu durumda özel istisna sınıfları oluşturmak uygun bir yöntem midir? Ya da InvalidOperationException, ArgumentException gibi özel türleri mi kullanmak gereklidir? Bu iki sorunun cevabı istisnaları kimin kullanacağıdır. Kullanacak olan sizseniz özel istisnalar oluşturmak korkunç bir düşüncedir. Burada unutulmamalıdır ki istisnalar kodda istisnai bir durumu belirtmek için kullanılır. Yani beklenmeyen bir durumu anlatmak için kullanılır.

Özel istisnalar ile ilgili bir kod yapısı oluşturulduğunda aşağıdaki gibi bir durum meydana gelecektir.

public string CreateCustomer(string name, string email)
{
   try
   {
     /* Creating a customer */
   }
   catch (EmailIsNotUniqueException)
   {
       return "The email provided already registered: " + email;
   }
   catch (CustomerNameIsInvalidException)
   {
       return "Customer name is invalid: " + name;
   }
   catch (CustomerAddressIsInvalidException)
   {
       return "Customer address is invalid";
   }
}

Bu kod yapısı C# diline uygun olsa da, hatta kullanışlı görünse bile iyi bir kullanım şekli değildir. Çünkü burada program akışı kontrol edilirken istisnalar kullanılmıştır ve istisnaların kontrol akışını sağlamak gibi bir görevi yoktur. Yukarıda da bahsettiğimiz gibi istisnalar istenmeyen bir durumu belirtmek için kullanılır.

Yazdığınız kodu sadece siz kullanacaksanız özel istisna sınıfları türetmenize gerek yoktur. İstisnalar yazılımınızdaki beklenmedik hataları bildirir ve işlemi tamamen sonlandırmanıza olanak verir. Ayrıca geçersiz bir girdi parametresinde olağan dışı bir durum yoktur ve bu sadece basit bir doğrulama hatasıdır.

Kendi oluşturduğunuz istisnaları, yürütme yığınının en üst düzeyindeki try-catch bloğunda yakalamak uygun bir yöntem olacaktır. İstisnaların burada log kayıtları tutulabilir ve kullanıcıya bir uyarı mesajı gönderilebilir. Örneğin Web Api için kullanıcıya 500 mesajı verilebilir.

Özel istisna türleri (custom exceptions) ve harici kütüphaneler

Yazdığınız kodu sizin dışınızda başka geliştiriciler de kullanacaksa istisnai durumlar için farklı bir yol izlenebilir.

Yazdığınız kütüphanede ortaya çıkan beklenmedik istisnai durumları nasıl ele alacağınızı siz bilmesenizde kütüphenenizi kullanan geliştiriciler bunu biliyor olabilir. Örneğin bir FTP client uygulaması kuruyorsunuz ve ana makine client uygulamaya cevap vermiyorsa bir çok kez deneme yapabilirsiniz. Bu durumda client uygulama kendi içerisinde sürekli yeniden bağlanmayı denerse işin içinde çıkılamaz. Bunun yerine kütüphanenizi kullanan geliştiriciye bağlantı hatası fırlatıldığında geliştirici bu durumda ne yapacağını kestirebilir. Sonuçta bağlantı sağlanamaması durumu ile nasıl başa çıkacağını kütüphane kullanıcısı bilir. Bu gibi durumlara karşı her kullanıcının alacağı önlem farklı olabileceğinden bu istisnai durumun özel bir tür olarak diğer istisnai durumlardan ayrılması gerekir. İşte özel istisna türlerinin yürütüleceği yer burasıdır. Oluşturulan özel istisnalar, kütüphane kullanıcılarının karşılaşabileceği her olası soruna karşı doğru tepki vermelerine yardımcı olur.

Özet

  • Özel istisna oluştururken SystemException ve ApplicationException gibi ketegori ayrımları kullanmak yerine Exception temel sınıfından yeni istisna sınıfları üretmek daha uygundur.
  • Eğer yazdığınız kütüphaneyi sizden başka kullanacak olan yoksa, özel istisna türleri oluşturmayın. Mevcut istisna sınıflarını kullanabilirsiniz. Ya da size özel tek bir  istisna türü oluşturarak her yerde kullanabilirsiniz.
  • Eğer bir kütüphane veya framework geliştiriyorsanız ilgili kütüphaneye özel istisna türleri oluşturun. Bu sayede kütüphane geliştiricisi olarak önceden kestiremeyeceğiniz durumlara karşı kullanıcılara bir emniyet önlemi sunmuş olursunuz.

Kaynak: http://enterprisecraftsmanship.com/2016/12/08/custom-exception-types/

ASP.NET Core geliştiriciler için yol haritası

5 Oca

2019 yılında, bir grup geliştirici, GitHub‘da ASP.NET Core geliştiriciler için bir yol haritası ortaya koymuşlar. Kaynağa buradan ulaşabilirsiniz.

Bu yazıda, her geliştirici için faydalı olabileceğini düşündüğüm bu yol haritasını sizlerle paylaşmak istedim.

Yol Haritası Boyunca Bilinmesi Gerekenler

  1. Öncelikle bilinmesi gerekenler.
    • C#
    • Entity Framework
    • ASP.NET Core
    • SQL Fundamentals
  2. Bilinmesi gereken genel geliştirme becerileri.
    • GIT sistemi öğrenilmeli, GitHub üzerinde yeni bir repository oluşturulabilmelidir, kod diğer geliştiricilerle paylaşılmalıdır.
    • HTTP(S) protokolü bilinmeli, http request metodları (GET, POST, PUT, PATCH, DELETE, OPTIONS) bilinmelidir.
    • Google kullanmaktan ve araştırmaktan korkmayın.
    • Dotnet CLI öğrenmelisiniz.
    • Veri yapıları ve algoritmalar hakkında bir kaç kitap okumalısınız.
  3. Dependency Injection (DI – Bağımlılıkların dışarıdan alınması)
  4. Veritabanları
  5. Cache Mekanizmaları
  6. Log Mekanizmaları
  7. Web site geliştirme şablonları (Template Engines)
  8. Gerçek zamanlı iletişim araçları (Realtime Communication)
  9. Nesne eşleştirme araçları (Object Mapping)
  10. API istemcileri (Clients)
  11. Bilinmesi faydalı olabilecek bilgiler
  12. Testler
  13. Görev zamanlayıcılar (Task scheduling)
  14. Mikro servisler (MicroServices)
  15. SOLID prensipleri
  16. Tasarım Kalıpları (Design-Patterns)

Yol Haritası Görseli