Tekrardan merhaba güzel insanlar, kaldığımız yerden devam ediyoruz :) Bu yazımda sizleri fazla detaya boğmadan Spring kütüphanesinin önemli bir özelliği olan Transactional anotasyonundan bahsetmek istiyorum.

Spring kütüphanesini kullanan projelere denk geldiyseniz muhakkak @Transactional diye bir anotasyonun kullanıldığını görmüşsünüzdür.

İyi güzel de nedir bu @Transactional anotasyonu neden kullanırız biraz bundan bahsedelim.

transaction

Aslında @Transactional anotasyonuna giriş yapmadan önce yazılım dünyasının önemli jargonlarından biri olan Transaction ifadesinin ne anlama geldiğinden biraz bahsetmek gerekir diye düşünüyorum.

Çoğu zaman uygulamalarımızın arkasında bir veri tabanı yatar ve uygulamamız veri tabanı üzerinde okuma, yazma gibi belirli işlemleri gerçekleştirir.

Transaction ifadesini aslında bu işlemlere benzetebiliriz, kısaca bir veya birden fazla sorgunun aynı süreçte işlem görmesidir.

Peki her zaman böyle midir? Her zaman olmasa da çoğunlukla evet, özellikle kurumsal ve birden fazla kullanıcıya hitap eden uygulamalarımız için böyle olmasını isteriz.

Şimdi tekrardan @Transactional anotasyonuna geçebiliriz :)

Spring’in önemli bir özelliği olan bu anotasyonu yukarıda Transaction olarak ele aldığımız okuma, yazma gibi işlemlerin daha sağlıklı yönetilebilmeleri adına kullanırız.

Peki bu mekanizma tam olarak ne işe yarıyor? İyi anlaşılması adına şu şekilde örnekleyebiliriz.

A diye bir metodumuz olsun, ve içinde sırasıyla X objesi için insert, Y objesi için update ve Z objesi için de delete işlemlerimiz olsun.

@Transactional
public void A() {
  //
  repository.insert(X);
  //
  repository.update(Y);
  //
  repository.delete(Z); 
  //
}

X objemiz için insert ve Y objemiz için update işlemlerimizin başarıyla gerçekleştiğini varsayalım, fakat sonrasında bir şeyler ters gitti ve metodumuz sona ermeden bir exception fırladı, peki şimdi ne olacak?

İşte tam bu arada Spring’in Transactional mekanizması devreye giriyor ve hata alınan kısma kadarki insert ve update işlemlerini geri alıyor. Böylece belirli veri tabanı işlemlerinden sonra hata alsak bile bu işlemleri veri tabanına yansıtmayıp, yaşanabilecek herhangi bir veri tutarsızlığının önüne geçmiş oluyoruz.

Tam aksine hata almayıp, metodun işini başarıyla bitirmesi durumunda Transactional mekanizması tüm işlemleri veri tabanına commit eder.

Transactional mekanızması default olarak herhangi bir RuntimeException fırladığı zaman rollback işlemini uygulayacak şekilde tasarlanmıştır, tabii ki bu davranışı değiştirmek mümkün. Mesela sadece şu exception/lar için rollback işlemini gerçekleştir tarzı bir şey diyebilmemiz gayet mümkün ve basit.

Umarım siz değerli okuyucularıma @Transactional anotasyonunun ne işe yaradığını bir nebze olsun anlatabilmişimdir :)

Bir sonraki yazımda görüşmek üzere, hoşça ve sağlıcakla kalın :)

Merhaba arkadaşlar, bu yazımda yazılım dünyasında oldukça sık duyduğumuz type-safety kavramından bahsedeceğim. Artıları ve eksileriyle birlikte değerlendirmeye çalışacağım.

Type-safety nedir

Type-safety kısaca; derleyicimizin derleme zamanında belirttiğimiz değişken tiplerini kontrol etmesi ve bir değişkene yanlış tipte bir atama yapıldığında hata vermesi anlamına gelir.

Type-safety özelliğinin mevcudiyeti dilden dile değişebilen bir durumdur. Java, C# gibi çoğu object-oriented dilde mevcut iken, Javascript, PHP gibi dillerde mevcut değildir.

Şimdi Java dili üzerinden type-safety kavramını basit örneklerle açıklayalım.

Employee employee = new Employer();

Yukarıda kod bloğunda gördüğümüz üzere Employee tipinde olan değişkene Employer tipinde değişken atadık. Yanlış tip ataması yaptığımız için kodumuzu derlemeye çalıştığımız zaman hata alacağız.

Not: Employee ve Employer sınıflarını birbirleriyle ilişkisi olmayan bağımsız sınıflarmış gibi düşünelim.

Yine başka bir örnek ile devam edelim;

String var1 = "string";
var1 = 5;

Burada da String tipinde olan var1 değişkenine sayısal bir değer atamaya çalıştık ve yine derleme zamanında hata alacağız.

Artıları ve eksileriyle type-safety

  • Type-safety dillerde yanlış tip atamalarından kaynaklı hatalar derleme zamanında yakalanırlarken type-safety olmayan dillerde çalışma zamanında yakalanırlar.
  • Type-safety olmayan diller derleme zamanında tip kontrolü yapmadıkları için daha esnek bir programlama sağlarlar.
  • Type-safety dillerde yanlış tip atamalarından kaynaklı hatalar derleme zamanında yakalandıkları için ilgili hatalar daha önce farkedilmiş olur.

Sonuç olarak; type-safety özelliği iyidir veya kötüdür diyemeyiz. Artılarını ve eksilerini birlikte değerlendirip, projemizin ihtiyaçlarını da göz önünde bulundurak bir sonuca varabiliriz.

Umarım type-safety kavramını siz değerli okurlarıma basit ve anlaşılır bir şekilde anlatabilmişimdir. Bir sonraki yazımda görüşmek üzere, hoşça kalın :simple_smile:

Merhaba arkadaşlar, bu yazımda RPC ve RMI kavramlarından ve sürekli bu kavramların karıştırılması adına birbirleri arasındaki farklardan bahsedeceğim.

RPC

RPC yani Remote Procedure Call Uzaktan Yordam Çağrısı anlamına gelmektedir. İsminden de tahmin edilebileceği gibi uzaktaki bir sunucuda bir yordamın çağırılması demektir.

RMI

RMI yani Remote Method Invocation bir yukarıda bahsettiğimiz RPC mekanızmasının Java ekosistemi için uyarlanmış bir implementasyonudur. RMI, Java yordamlarının lokalde veya uzaktaki başka bir Java ortamında çağırılmasına olanak tanır.

RPC ve RMI arasındaki farklar

  • RMI RPC mekanızmasının bir Java implementasyonudur.
  • RMI Java Sanal Makinesi üzerinde çalıştığından dolayı daha yavaştır.
  • RPC yordamsaldır, RMI nesneye yöneliktir.
  • RPC’yi programlamak daha zordur.

RPC ve RMI kavramlarından siz okurlarımı çok detaya boğmadan kısaca bahsetmeye çalıştım. Bir dahaki yazımda görüşmek üzere, hoşçakalın :)

Merhaba arkadaşlar. Yazılarımıza kaldığımız yerden devam ediyoruz :). Bu yazımda da Java’daki Checked Exception ve Unchecked Exception kavramlarından bahsedeceğim.

Konuya girmeden önce Java’daki exception hiyeraşisini bir hatırlayalım.

Hiyeraşiye şöyle bir göz attıktan sonra artık konumuza geçebiliriz.

Unchecked Exception

İsminden de anlaşılacağı gibi derleyici tarafından kontrol edilemeyen exceptionlardır. Derleyici tarafından kontrol edilemedikleri için kodumuz başarıyla derlenmiş olsa bile çalışma zamanında bu hatalarla karşılaşabiliriz.

Unchecked Exceptionlar RuntimeException‘ın alt sınıflarıdır. Bunlardan en yaygınları ArithmeticException , NullPointerException , ClassCastException… gibi exceptionlardır.

Aşağıdaki kod bloğuna bakalım;

public static void main(final String[] args) { 
   try { 
       FileReader file = new FileReader("example.txt"); 
       file = null; file.read(); 
   } catch (final IOException e) { 
       e.printStackTrace(); 
   } 
}

Yukarıda görüldüğü üzere file nesnemiz null ve program akışı file.read()  komutuna geleceği zaman NullPointerException fırlatacağını rahatlıkla söyleyebiliriz. Fakat NullPointerException bir Unchecked Exception olduğundan dolayı bizim bu durumu belirtmemize gerek yok ve derleyici kodumuzu başarıyla derlememize izin verir dolayısıyla biz bu hata ile ancak çalışma zamanında karşılaşırız.

Checked Exception

İsminden de anlaşılacağı üzere derleyici tarafından kontrol edilen exceptionlardır. Derleyici tarafından kontrol edildikleri için biz bu exceptionları kodumuzda belirtmek zorundayız. Aksi halde derleme işlemini başarıyla tamamlamak mümkün değildir.

Checked Exceptionlar Exception sınıfının alt sınıflarıdır ( RuntimeException hariç). En yaygınları ClassNotFoundException, IOException, SQLException… gibi exceptionlardır.

Şimdi aşağıdaki kod bloklarına göz atalım;

public static void main(final String[] args) { 
    final FileReader file = new FileReader("example.txt"); 
}

Yukarıdaki gibi yazdığımız zaman derleyici tarafından hata alırız ve kodumuz başarıyla derlenmez çünkü belirtmemiz gereken ilgili Checked Exception’ını belirtmedik.

public static void main(final String[] args) { 
    try { 
        final FileReader file = new FileReader("example.txt"); 
    } catch (final FileNotFoundException e) { 
        e.printStackTrace(); 
    } 
}

Yukarıdaki gibi yazdığımız zaman kodumuz artık başarıyla derlenecektir çünkü bir Checked Exception olan FileNotFoundException‘ını kodumuzda belirtmiş olduk.

 

Unchecked Exception ve Checked Exceptionlarıyla ilgili anlatacaklarım bu kadar umarım kafanızda herhangi bir soru işareti kalmamıştır. Lütfen yorumlarınızı esirgemeyiniz, bir dahaki yazımda görüşmek üzere :)

 

 

 

Merhaba arkadaşlar, bu makalemde bir Agile yazılım geliştirme tekniği olan Pair Programming tekniğinden bahsetmek istiyorum. Pair Programming Türkçe’de eşli programlama veya ikili programlama olarak geçmektedir fakat makale boyunca Pair Programming olarak bahsedeceğim.

Pair Programming aslında isminden de çıkarım yapılacağı gibi temel olarak iki kişinin tek bir kod bloğu üzerinde çalıştığı bir tekniktir. Yazılım geliştiricilerden biri izleyici diğeri sürücü konumundadır. Sürücü özenle kod yazmaktan sorumlu iken izleyici sürekli gözlemlemek ve yönlendirmekten sorumludur.

Pair Programming

Pair Programming in en büyük avantajı gözlemci ile beraber daha hatasız ve doğru bir şekilde kod yazılmasıdır. Diğer önemli bir avantajı ise bu tekniği uygulayan ekiplerin, birbirlerinin gelişimine önemli bir şekilde katkı sunmasıdır. Bu tekniğin çok bir dezavantajı olmasada kaynakların verimsiz kullanıldığı algısı oluşabilir.

Türkiye’de şu an çok tercih edilmese de oldukça verimli bir geliştirme süreci sağlamaktadır.

Lütfen yorumlarınızı esirgemeyiniz :) bir dahaki yazımda görüşmek üzere..