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

Alert, Event ve Log arasındaki farklar

11 Ara

Yazılımsal bir ekosistemin yönetim ortamında görülmek istenen bazı temel raporlar vardır. Bu yazıda bir birine benzeyen ve bazen karıştırılabilen alert, event ve log kavramlarından bahsedilmektedir.

Alert

Bir alert(alarm), sistemde meydana gelebilecek sıra dışı olaylar olarakdır. Örneğin;

  • Sunucu disk kapasitesinin %90 kullanım oranına ulaşması.
  • Sistemdeki IoT cihazlarının N tanesinin birden kapanması veya hata durumu bildirmesi. (N eşik değer)
  • N tane kullanıcının birden gün içinde bloklanması. (N eşik değer)

Bu ve buna benzer olaylar, sistemin yönetim biriminde raporlar veya bildirimler(sms, email, ses) şeklinde alarm olarak tutulabilirler. Alarmlar genellikle sistemin sağlıklı devam edebilmesi için bildirilen kritik uyarılardır. Belirli bir olay gerçekleştiğinde, sorumlu kişilerin veya sistemlerin harekete geçmesini sağlamak amacıyla yapılan bildirimler olarak da düşünülebilir.

Event

Bir event(olay), sistemde meydana gelebilecek sıradan olaylardır. Örneğin;

  • Yeni kullanıcı kaydı yapıldı.
  • Kullanıcı aktif edildi.
  • Kullanıcı silindi.
  • Sipariş alındı.
  • Sipariş onaylandı.

Bu ve buna benzer rutin olaylar, event olarak kaydedilirler. Sistemde meydana gelen rutin akışın takibi ve kaydı için gerekli bir kayıt kütüğü olarak düşünülebilir.

Log

Kelime anlamı günlük olan log, sistemde meydana gelen olayların otomatik olarak üretilir ve zaman damgalı olarak kaydedilir. Örneğin;

  • Veri tabanı bağlantı hataların detaylarıyla birlikte kaydedilmesi.
  • Servis talebinin olumsuz cevap alması.

Log kayıtları, istenilen seviyede tutulabilir. Bu seviyeler, Info, Warning, Error, Fetal, Debug şeklinde gruplandırılabilir.

  • Info, genellikle sistemdeki yararlı bilgiler şeklinde düşünülebilir. İhtiyaç duyulduğunda bilgi mahiyetinde bakılabilecek kayıtlardır.
  • Warning, sonuçları otomatik olarak düzeltilebilecek, uyarı niteliğindeki bilgilerdir.
  • Error, işlemlerin devam edememesi durumunda kaydedilen bilgilerdir. Sistem yöneticisinin müdahalesini gerektirir.
  • Fetal, sistemin durması veya veri kayıplarının yaşanabileceği durumlarda kaydedilen bilgilerdir.
  • Debug, geliştirme sırasında geliştiriciye bilgiler veren kayıtlardır.

Sonuç

Alert, Event ve Log bilgileri, sistemin yönetilebilirliği açısından çok önemlidir. Bu kayıtlar tutulmadığı taktirde, sistemde ne olup bittiğinden haber alınamaz. Bu tür kayıtlar, bir veritabanında veya dosyalarda tutulabilir. Proje büyüklüğüne göre genellikle log kayıtları dosyalarda, alert ve event kayıtları, veritabanı tablolarında tutulurlar. Bu sayede, alert ve event bilgileri, gösterge panelleri(dashboard) ve raporlarda çıktı olarak alınabilir.

PostgreSQL Veritabanı ve Tablo Boyutları Nasıl Öğrenilir

9 Ara

PostgreSQL üzerinde tanımlanan bir veritabanı veya veritabanı üzerinde tablolarının boyutlarını öğrenmek mümkündür. Bu işlemler için PostgreSQL komutları kullanılır. Komutları, psql komut satırı veya PgAdmin gibi araçlar kullanılabilir.

1. Veritabanı boyutunu veren komut

Aşağıdaki komutta ‘veritabanı_adı’ kısmına kendi veritabanınızı yazabilirsiniz.

SELECT pg_size_pretty(pg_database_size('veritabanı_adı'));

2. Veritabanı tablo boyutunu veren komut

Aşağıdaki komutta ‘tablo_adı‘ kısmına kendi veritabanı tablo adınızı yazabilirsiniz.

SELECT pg_size_pretty(pg_total_relation_size('tablo_adı'));

 

Javascript unary plus (+) operator

30 Haz

Javascript ve diğer programlama dillerinde artı (+) ya da plus (+) operatörü,  toplama işlemi için kullanılmaktadır. Ancak (+) operatörünün Javascript dilinde geliştiricilere avantaj sağlayan bir özelliği daha bulunmaktadır. (+) operatörü, önünde bulunduğu operand eğer sayı değilse, onu sayıya dönüştürmeye çalışır. Operatörün kullanımı şu şekildedir:

+degisken

Yani sadece değişkenin önüne bir (+) işareti eklenir.

Dönüştürülebilen Türler

(+) operatörü aşağıdaki türleri sayıya dönüştürebilir:

  • string (sayı olarak)
  • null
  • boolean
  • integer (pozitif veya negatif)
  • float (pozitif veya negatif)
  • 0x formatındaki onaltılık sayılar.
  • scientific (exponent)  bilimsel üslü sayılar.

Dönüştürülemeyen Türler

(+) operatörü, sayıya dönüştüremediği değerleri NaN olarak verir.

  • undefined
  • string (yazılar)

Örnek

console.log(+”09″);  // Output: 9

console.log(+null);  // Output: 0

console.log(+”7″);   // Output: 7

console.log(+”-7″);  // Output: -7

console.log(+”-3.14″);  // Output: -3.14

console.log(+”3.14″);  // Output: 3.14

console.log(+false);   // Output: 1

console.log(+false);  // Output: 0

console.log(+”0xFF”);  // Output: 255

console.log(+”123e-5″);  // Output: 0.00123

console.log(+”xxx”);   // Output: NaN

console.log(+”undefined”);   // Output: NaN

Sonuç

(+) operatörü yani unary plus operatörünün Javascript dilinde kullanımı örneklerle desteklenerek incelenmiştir. (+) operatörünün pek bilinmeyen ve kullanılmayan bir kullanımı anlatılmıştır.