Soyutlamalar

Oct 27 2017 Published by under java, software development

Yazılımcılar olarak bir iş mantığını daha hızlı ve kolay geliştirmek için çoğu zaman soyutlamalar (abstractions) kullanırız. Sık ve farklı istemciler tarafından kullanılan bir iş mantığını soyutlayıp istemcilerin işini kolaylaştırmaya çalışırız. Dar boğazımız “zaman kısıtı” ise soyutlama kullanmak çoğu zaman işe yarar ama dezavantajları da beraberinde gelir. Joel Spolsky “The Law Of Leaky Abstractions” başlıklı makalesinde TCP protokolü üzerinden örnek vererek her soyutlamanın mutlaka bir seviye sızdıracağından bahseder. Sızdırmaktan kasıt ise alttaki bir protokolün üzerine soyut bir protokol geliştirildiğinde, hala alttaki protokolle ilgilenme ihtiyacı duymamızdır. Soyutlamadaki alt katmana sızdıran delik ne kadar büyükse karmaşıklık o kadar artar ve işimizi kolaylaştırsın diye seçtiğimiz mantık ayağımıza dolanır. Ne soyutun avantajlarını yeteri kadar kullanabiliriz ne de onu çöpe atıp direk bir alt katmanı kullanabiliriz. Bunu ben en çok tam iki kat arasında kalmış bir asansöre benzetiyorum. Ne tırmanıp üst kattan çıkabilirsiniz ne de eğilip alt kattan. Sıkışıp kalırsınız.

Bu konuyu gündeme getirmemin sebebi yukarıda bahsettiğim gibi her gün bununla çok sık karşılaşmam. Örneğin Redis gibi bir bellek/veri tabanı kullanıyorsanız Redis’in komut satırından çalıştırabildiğiniz onlarca komut bulunuyor. Bu komutların ne iş yaptığını Redis’in kendi dokümantasyonundan net bir şekilde biliyorsunuz. Java programlama dili kullanıyorsanız Redis’e genellikle Jedis isimli istemci kütüphanesi aracılığıyla erişiyorsunuz. Burada bir seviye soyutlama bulunuyor zira Redis komutlarının küçük bir kısmını Jedis ile kullanamıyorsunuz. Bir de Jedis’in üzerine spring-data-redis gibi bir kütüphane daha kullanıyorsanız Redis komutlarının üzerine iki kat çıkmışsınız demektir. Operasyonlarda işiniz kolaylaştı fakat Redis’ten de iki kat uzaklaştınız. Varsayalım ki kullandığınız kütüphanelerden bir tanesi bir NullPointerException fırlatıyor. Buradan itibaren artık tamamen “Leaky Abstraction” kavramıyla karşı karşıyasınız demektir ve sorunun çözümü için ters mühendisliğe ihtiyaç duyacaksınız. Kat kat çıktığınız soyutlamaların sızdıran deliklerinden birer birer alt katlara ineceksiniz.

Örneğin spring-data-redis’in RedisOperations.java sınıfını açıyorsunuz ve şu şekilde bir kod dokümantasyonu göze çarpıyor:

“ Returns the operations performed on simple values (or Strings in Redis terminology) bound to the given key.”

Meali: Redis’teki basit operasyonları döner. Biz buna boundValueOps dedik ama bu aslında Redis terminolojisine göre String operasyonlarına karşılık geliyor.

Sızdıran delikten bir alt kata indiniz ve oradaki bir terimin aslında Redis’teki String operasyonları yaptığını öğrendiniz ve problemin karmaşıklığına göre en alt kata kadar inebilirsiniz.

Sonuç olarak biz yazılımcılar sürekli soyutlamaların sızdıran deliklerinden girip çıkıyoruz ve bu konuyu henüz çözebilmiş değiliz. Programlama tarihi de düşük seviyeden başlayıp en yüksek seviye programlama dillerine evrildi (Nesne yönelimli, belleği kendi yöneten diller). Hatta sürükle-bırak yaparak program yazılabileceğini iddia edenler dahi oldu. Bir takım donanım kısıtlarına gelindiğinde ise tekrar düşük seviye diller popüler olmaya başladı (Paralel programlama, Fonksiyonel programlama..vs.). Karşılaştığımız problemlere ve dar boğazlara göre ömrümüz kat kat soyutlamalar arasında inip çıkmakla geçecek gibi görünüyor. 🙂

Yazıya medium’dan da erişebilirsiniz: https://medium.com/@yyenigun/soyutlamalar-478437b70144

Comments are off for this post

Spring Boot 1.3’ten 1.4’e geçiş rehberi

Aug 22 2016 Published by under java, software development

28 Temmuz 2016 itibariyle Spring Boot 1.4 versiyonu yayınlandı. Bu versiyonla birlikte başta test altyapısı olmak üzere birçok değişiklik yayına alındı. Spring Boot 1.3’ten Spring Boot 1.4’e geçiş yapacaklar için bir rehber hazırladım.

Bağımlılıklar:

İlk olarak pom.xml veya build.gradle dosyasında Spring Boot versiyonunun 1.3.x.RELEASE ‘den 1.4.0.RELEASE‘e çekilmesi gerekiyor.

JPA:

Eğer JPA kullanılıyorsa @EntityScan notasyonunun paketi değişti. Kullanılan import’larda bu paket değişikliğinin yapılması gerekiyor:

Eskisi:

Yenisi:

Testler:

Eğer Spring’in test arayüzü kullanılıyorsa burada da kullanılan notasyonlar değişti. SpringJUnit4ClassRunner yerine SpringRunner geldi. @SpringApplicationConfiguration yerine de @SpringBootTest kullanıluyor:

Eskisi:

Yenisi:

Aynı zamanda assertj’nin versiyonu arttı. Burada da kullanılan assertThat metodunun paketi değişti:

Eskisi:

Yenisi:

Hibernate:

Hibernate 4’ten Hibernate 5’e geçildi. Bu büyük bir değişiklik ve eğer büyük problemler yaratırsa Hibernate geçiş rehberine göz atılabilir:

https://github.com/hibernate/hibernate-orm/blob/5.0/migration-guide.adoc

Spring Boot 1.4 Sürüm Notları:

https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-1.4-Release-Notes

Comments are off for this post

Spring 4’le Gelen Yenilikler

Sep 19 2014 Published by under java

İlk sürümü 2004 yılında çıkan Spring Framework’ün şu ana kadar çok kez büyük sürümü çıktı. Spring 2.0 ile XML ve AspectJ desteği, Spring 2.5 ile notasyon (annotation) konfigürasyonu ve Spring 3.0 ile de Java tabanlı konfigürasyon modeli geldi.

Spring’in en son büyük (major) sürümü olan Spring 4.0 ile gelen en büyük yenilik ise Java 8 desteği. Spring 4.0 ile gelen tüm yenilikler :

1. Spring’e Başlangıç deneyiminin iyileştirilmesi

Spring’in yeni web sitesine (http://spring.io/)  Spring’e başlangıç ve Spring’i öğrenme dokümanlarının tamamı eklendi:  http://docs.spring.io/spring/docs/current/spring-framework-reference/html/overview.html

 2. Son kullanma tarihi geçmiş (deprecated) paketlerin ve metodların silinmesi

Versiyon 4 ile birlikte son kullanma tarihi geçmiş (deprecated) birçok metot ve sınıf kaldırıldı. Eğer projelerinizdeki Spring versiyonunuzu Spring 4’e yükseltmek istiyorsanız Java’nın son kullanma tarihi geçmiş metod, sınıf ve arayüzlerini kaldırdığınızdan emin olmanız gerekiyor. Kaldırılan tüm işlevleri görmek için şu doküman kullanılabilir: http://docs.spring.io/spring-framework/docs/3.2.4.RELEASE_to_4.0.0.RELEASE/

3. Java 8 (Java 6 ve Java 7 ile birlikte)

Spring 4 ile birlikte gelen en önemli yenilik Java 8’in bazı özelliklerini desteklemesi. Spring’in callback arayüzleri ile Lambda ifadelerinin kullanımı sağlandı. Halihazırdaki bazı notasyonların (ör: @Repeatable) java.time (JSR-310) paketini desteklemesi sağlandı. Geriye uyumlu olan versiyon 4 Java 6 ve Java 7 ile de kullanılabilir.

4. Java EE 6 ve 7

Spring 4 JPA 2.0 ve Servlet 3.0 versiyonları ile birlikte Java EE 6 ve üstü için temel versiyon haline geldi. Aynı zamanda JMS 2.0, JTA 1.2, JPA 2.1, Bean Validation 1.1 ve JSR-236 Concurrency kütüphaneleri gibi temel Java EE 7 standartlarını destekler duruma geldi.

5. Groovy Bean Tanımlamaları (Groovy DSL)

Spring Framework 4.0 ile birlikte Groovy DSL kullanarak bean konfigürasyonu yapılabilir hale geldi. Yazım olarak XML konfigürasyonuna benzese de konfigürasyon yazımı XML’e göre kısaldı. Örnek:

6. Container iyileştirmeleri

Bean’leri enjekte ederken “generic” tiplerin de kullanılabilmesi sağlandı.

7. Genel Web İyileştirmeleri

Spring MVC uygulamalarında @RestController notasyonunun kullanılması sağlandı.

8. WebSocket Mesajlaşma

Spring’in yeni spring-websocket modülü ile client-server web uygulamalarında çift yönlü iletişim sağlandı.

9. Test İyileştirmeleri

Yeni SocketUtils sınıfı sayesinde TCP/UDP soketleriyle entegrasyon testleri yapılabilir hale geldi.

Comments are off for this post

Ehcache vs Hazelcast

Jan 12 2013 Published by under software development

Bu yazıda iki açık kaynak kodlu dağıtık bellek ürününün karşılaştırmasını yapmak istiyorum. Bunlardan biri Terracota firmasının Apache lisansına sahip ürünü Ehcache (http://ehcache.org/), diğeri ise İstanbul’dan çıkıp açık kaynak kod dünyasına hızlı bir giriş yapmış olan Hazelcast. (http://www.hazelcast.com/)

Google Trends’in verilerine göre Ehcache’de yavaş bir düşüş varken, Hazelcast’te piyasaya yeni girmiş olmasından kaynaklanan bir yükseliş bulunuyor.

Ehcache:
ehcache

Hazelcast:
hazelcast

İki ürünün açık kaynak kodlu versiyonlarını karşılaştırdığımızda Hazelcast önde gözüküyor. Sebeplerine gelirsek Hazelcast’in açık kaynak kodlu versiyonunda dağıtık bellek (distributed cache) olarak genişletilebilir (scalable) bir bellek sunucusu (cache server) varken Ehcache’in açık kaynak kodlu versiyonunda ayrı bir bellek sunucusu yok ve dağıtık bellek, nesne kopyalama (object replication) ile sağlanıyor. Ehcache’te ayrı bir bellek sunucusuna (Terracota Array) sahip olabilmek için kurumsal versiyonu satın almak gerekiyor. İki ürün de konfigürasyon altyapısı olarak JMX’i desteklemekle beraber Hazelcast açık kaynak kodlu versiyonunda web arayüzü ile yönetime de imkan tanıyor. Ehcache’te ise bu imkan kurumsal (enterprise) versiyonda bulunuyor. Bu açılardan Hazelcast bir adım önde görünse de Ehcache’in arkasındaki halk desteği (community support) daha güçlü.

Her kurumun kendi gereksinimlere göre bu iki üründen birini seçme özgürlüğü var fakat küçük bir genelleme yapmam gerekirse küçük firmalar (start-up) için Hazelcast daha uygun görünüyor zira Ehcache’e göre kullanımı çok daha kolay ve bedavaya Ehcache’in kurumsal versiyonunda olan bir çok özelliğe sahip olmak mümkün. Kurumsal firmalar için ise Ehcache tercih edilebilir çünkü hem arkasında Terracota isimli görece güçlü bir firma var hem de Hazelcast’e göre daha oturmuş ve riski az bir ürün.

Bu arada iki ürünün de Spring entegrasyonu bulunuyor şöyle ki @Cacheable notasyonuyla (annotation) belleğe atılan bir veri yapısı, altyapıdaki bellek ürünü değiştirilse de çalışıyor. Dolayısıyla altyapıdaki bellek ürünü, koda dokunmadan sadece konfigürasyonla değiştirilebiliyor.

Not: Bir de şöyle bir karşılaştırma var: http://stackoverflow.com/questions/5245487/hazelcast-vs-ehcache/5271450#5271450

Comments are off for this post