Category Archives: JAVA

UNIT TESTING & TDD (Test Driven Development)

Posted by İbrahim DEMİR on 29/08/2007 3 comments

Geçtiğimiz haftadan bu yana üzerinde çalıştığımız projenin test aşamasını iyileştirebilmek (yada gerçekleştirebilmek) adınatest.jpg Unit Testing ve Test Driven Development ile ilgili araştırmalar yapıyorum. Bu süreçte bir yandan birşeyler öğrenme bir yandan da bu öğrendiklerimi hali hazırda yürüttüğümüz projeye uygulama şansına sahibim. Bu nedenlerden ötürü geçtiğimiz haftayı Unit Testing ve Test Driven Development üzerinde araştırma yaparak geçirdim. Bu noktada bana düşen en önemli görev developer arkadaşları Unit Test yazmanın bir lüks değil bir gereklilik olduğuna ikna etmek. O nedenle bu gerekliliğe kendimi iyice inandırmaya çalıştım ve yüzlerce linki , yazıyı taradım. Bu süreçte öğrendiklerimi belirli başlıklar altında sizlere paylaşmak güzel olacaktır diye düşündüm.

(NOT: Test-Driven Development = Test Güdümlü Yazılım Geliştirme ,Unit Test= Birim Testi olarak kullanılacaktır.)

Test Güdümlü Yazılım Geliştirme Nedir?

Test Güdümlü Yazılım Geliştirme: önce gerekli test koşullarını yazıp ardında da bu testleri geçecek ve hedeflenen işi yapacak kodu yazmayı öngören bir yazılım geliştirme modelidir.

Bu yazılım geliştirme modeli dahilinde aşağıdaki adımlar izlenir:

• Öncelikle yazılımın ilgili birimi için basitçe bir test yazılır.
• Bir sonraki adımda teste tabi tutulacak birim yazılır.
• Eğer o birim, testi geçerse test geliştirilir ve birim tekrardan test edilir.
• Eğer birim testi geçemezse gerekli değişiklik yapılır ve tekrar test edilir.
• Birim son halini alana kadar her değişiklikte test edilir.
• Birim beklenen işi gerçekleştiriyorsa ve tüm testleri geçiyorsa süreç tamamlanır.

Test Güdümlü Yazılım Geliştirme , geliştirme sürecimizi hem hızlandırır hem de iyileştirir çünkü yazılan kodların bir hata durumunda tekrardan yazılması veya hatanın bulunmaya çalışılması ciddi bir maliyet oluşturur.
Test Güdümlü Yazılım Geliştirme yöntemi bir Sürüm Yönetim Sistemiyle birlikte kullanılırsa çok daha verimli olacaktır çünkü bu yaklaşım hata durumunda tüm testleri geçen sürüme geri dönülmesi kolaylığını getirir ve de kodun içerisinden hata ayıklamaktan daha efektiftir.

Birim Testi Nedir?

Birim Testi yazılım projemizdeki her bir birimin (Object-Oriented Programming çerçevesinde en küçük birim sınıftır) doğru bir şekilde çalışıp çalışmadığını anlamak amacıyla oluşturduğumuz testtir.

Birim testi hem Test Güdümlü Yazılım Geliştirme Sürecini kolaylaştırır hem de uygulamamızın her bir biriminin sorunsuzca çalıştığından emin olmamızı sağlar.

Neden Önce Birim Testi Yazılmalıdır ? (Test-First Approach)

Yazılım geliştiriciler için Birim Testi yazmanın yada Test Güdümlü Yazılım Geliştirme Süreci ‘ne adapte olmanın en zor noktası henüz yazılmamış bir birim için test yazmaktır. Bu noktada alışkanlıkların değiştirilmesi biraz zaman alabilir.

Testi , işi yapacak birimden önce yazmamızın nedeni: testi yazabilmek için o teste tabi tutulacak birimin ne iş yapacağını iyice anlamamızı gerektirmesidir. Eğer ilgili birimin verilen giriş bilgisine karşılık çıkışta ne üreteceğini iyice anlamışsak ancak o koşulda testini yazabiliriz. Testi yazdıktan sonra da o testi geçecek kodu yazmak daha kolay olacaktır çünkü testin yazımı sırasında o birimin yapacağı iş kafanızda netleşmiş olur.

Birim testini önce yazmak konusunda yapılan en büyük hata; ilk seferde doğru testi ve bu teste uygun birimi yazmayı hedeflemektir. İlk başta hem test hem de teste tabi tutulacak birimde hatalar ve eksiklikler olabilir fakat test ve düzeltme süreci yukarıda bahsedildiği şekilde tekrarlandıkça bu süreç sonunda ortaya daha kaliteli ve daha güvenilir bir ürün ortaya çıkacaktır.

Birim Testini Projemdeki Hangi Bileşenler İçin Yazmalıyım?

Bu noktada karar uygulama geliştiriciye aittir. Fakat Nesne Yönelimli Programlamada genel yaklaşım bir sınıf içerisindeki tüm public metodlar için birim testi yazmak yönündedir.

Öte yandan değişkenlere erişimi düzenlemek amaçıyla kullandığımız (Accessors- Mutators) metodlar ve bir bakışta işlevi anlaşılıp hata olduğunda kolaylıkla bulunabilecek metodlar için birim testi yazılmayabilir.

Tüm metodlar için birim testi yazmamanın tek dezavantajı projemizin Code Coverage (Code Coverage:Bir projedeki test edilen kodların, tüm kodlara oranı ) yüzdesini düşürmesidir.

Birim Testi ile İşlevsellik Testi (Functional Test) Arasındaki Temel Fark Nedir?

Birim Testi uygulama geliştiricinin kendi perspektifinden, yazdığı kodun doğru çalışıp çalışmadığından emin olmak amacıyla yapılırken , İşlevsellik Testi kullanıcının perspektifinden bakılarak yazılan kodun kullanıcı ihtiyaçlarını karşılayıp karşılamadığını tespit etmek amcıyla yapılır.

Birim Testi kod yazımından önce yapılırken , İşlevsellik Testi ürün müşteriye verilmeden evvel yapılır.

Birim Testinin Yazılım Geliştirme Sürecine Katkıları Nelerdir?

• Refactoring işlemlerini kolaylaştırır: Tüm birim testlerden başarıyla geçmiş bir kod bloğu üzerinde refactoring yaptığınızda kodunuzun bozulup bozulmadığını birim testini tekrar çalıştırarak rahatlıkla anlayabilirsiniz.
• Sonradan ortaya çıkabilecek hataların oluşturacağı maliyeti en aza indirir.
• Yazılımış kodları inceleme (Code Inspection) işleminden daha kolay ve daha verimlidir.
• Uzun vadede testsiz kod yazmaktan daha hızlı kod yazmayı sağlar çünkü aynı kodların hata durumunda tekrardan düzenlenmesi ihtiyacını en aza indirger.
• Birim testi yazmak, bizleri yazacağımız kodun işlevini en ufak detayıyla anlayama iter çünkü işlevini tam olarak anlayamadığımız bir birimin testini yazma şansımız yoktur. Bu da yazılan birimlerin daha doğru olmasını sağlar.
• Yazılan kodlar için bir çeşit dökümantasyon sağlar çünkü yazılan test koşulları incelenerek o kod bloğunun işlevi rahatlıkla anlaşılabilir.

Yukarıda bahsi geçen konularla ilgili öğrenme sürecim hala sürüyor o nedenle blogumda bu konuyla ilgili paylaşımlara devam edeceğim. Kısa bir süre içinde bu konuyla ilgili faydalanabileceğiniz linkleri kategorize ederek sizlerle paylaşmayı planlıyorum. Şimdilik benden bu kadar. Bir sonraki yazıma kadar sağlıcakla kalın…

NOT: Bu gece 3 gün sürecek ufak bir İzmir tatiline çakacağım. Umarım orada da blogumu güncellemeye fırsatım olur?

KARİYERİNİZE TURKCELL ‘DE YÖN VERMEYE NE DERSİNİZ?

Posted by İbrahim DEMİR on 19/08/2007 5 comments

turkcell_oracle1.jpgDaha önce blogumda IBM ve Microsoft ‘taki yaz okulu ve staj çalışmalarından bahsetmiş ve bunların önemini vurgulamıştım. Bu sırada çok önemli bir çalışmayı atladığımı fark ettim ve geç de olsa yolun başındaki arkadaşlara yol göstermesi açısından bu konuyu bloguma taşımaya karar verdim.
Turkcell ‘de son senelerde yoğun bir emek harcanarak R&D Software Development ekibine stajyer arkadaşlar alınıp , eğitilerek kariyerlerinde önemli bir adım atmaları sağlanıyor.

Eğer bu süreci yeterince iyi bir şekilde değerlendirirseniz kariyerinize Turkcell ‘de devam etme şansınız da var. Şöyleki staj döneminden sonra part-time çalışma şansına ardından da okul bitiminde full-time çalışma şansına sahip olabilirsiniz.

Her yılın Temmuz ayında başlayan ve Eylül ayının sonunda biten 3 aylık bir süreci kapsıyor bu staj dönemi. Burada 3 ay staj yapmak zorunlu. Yani yoğun ve ciddi bir staj dönemine hazırlıklı olun. Elbette bu dönem sonunda da kolay kolay hiçbir yerde elde edemeyeceğiniz bir bilgi birikimine sahip oluyorsunuz.

Staj döneminiz Turkcell ‘in kullandığı teknolojilere bağlı olarak Oracle ve Java ağırlı bir çalışma dönemini kapsıyor. Bu konularda üç aylık bir dönemi kapsayan teori ve uygulamayı birarada bulabileceğiniz bir staj dönemi geçiriyorsunuz. Burada Turkcell ve Oracle kelimelerini yanyana görmek sizlere birisini çağrıştırdı mı?

Evet bildiniz Hasan Tonguç YILMAZ. Eğer bu staj sürecine dahil olursanız Hasan Tonguç YILMAZ ile birlikte çalışma ve kendisinin deneyimlerinden faydalanma şansına da sahip olacaksınız. Kendisini tanıyanlar ve blogunu takip edenler Tonguç Abi ‘nin engin Oracle bilgisini sadece kendi işi için kullanmayıp etrafındaki kişilere çeşitli yollarla (forumlar,e-mail grupları , blog yazıları vb. ) paylaştığını bilirler. (O nedenle benim gözümde pek çok Oracle uzmanından daha değerlidir.)

Burada en önemli nokta paylaşımın ve iletişimin staj döneminden sonra da devam etmesi. Açıkcası benim öğrenciyken en çok imrendiğim ve başımı taşlara vurmama sebep olan nokta bu olmuştu. (Tonuguç Abi ‘nin Oracle Cost-Based Optimization çalıştayında stajyerlerine ne kadar çok değer verdiğini ve ne kadar çok şey kattığını görünce kıskanmadım desem yalan olur.)

Yazının başında da belirttiğim gibi şu anda staj süreci sürüyor. Bir sonraki alımlar seneye yapılacak ama şimdiden hazırlık yapmakta fayda var. Bu blog yazısına özel bir kaç da tüyo vereyim. Eğer Turkcell ‘deki bu staj sürecine kabul edilmek istiyorsanız önünüzdeki bu eğitim öğretim yılını çok iyi değerlendirin ve SQL, PL/SQL, APEX, JAVA konularına ağrılık verin. Bu noktada yapabileceğiniz en faydalı şey ara projenizi veya diğer derslerden aldığınız projeleri bu teknolojileri kullanarak gerçekleştirmek olacaktır.

Bu teknolojilerle ilgili olarak Oracle ‘ın sitesinde fazlasıyla kaynak mevcut. Ama ben yine de APEX (Application Express) ile yeni tanışacak olanların bu yazıya ve Oracle ile yeni tanışacak olanların da bu yazıya bakmalarını önereceğim. Turkcell ‘deki bu staj süreci ile ilgili olarak Hasan Tonguç Yılmaz ‘ın blogunda yazdığı bu yazıya bakmak da faydalı olacaktır. Yine aynı şekilde staj süreci hakkında bilgi alabileceğiniz diğer bir kaynak da şu anda hala stajyer olarak Turkcell ‘de bulunan Bilal Hatipoğlu ‘nun Blogu. Bilal gerçekten de çok yalın ve anlaşılır bir dille bu süreci ve öğrendiklerini bloguna taşımış. (Bu güzel paylaşımından ötürü Bilal ‘i tebrik ediyorum.)

Umarım bu blog yazısı öğrenci arkadaşlar için motive edici ve yol gösterici olur. Bu yıl içerisinde gereken çabayı gösterip yazıda bahsi geçen teknolojilere odaklanarak seneye siz de Turkcell ‘de stajyer olmaya ve kariyerinize yön vermeye ne dersiniz?

ECLIPSE İÇİN QUANTUM DB

Posted by İbrahim DEMİR on 09/08/2007 8 comments

Hangi Java mail grubuna yada forumuna bakarsanız bakın konu dönüp dolaşıp IDE (Integrated Development Environment) konusuna gelmiştir. Hatta bir kısım Javacı arkdaşlar bu tartışmalardan ve belirsizlikten bunalıp kendilerini .NET platformunun dolayısıyla Visual Studio ‘nun sıcak kollarına atmışlardır. Her ne kadar Visual Studio gibi kur ve kullan başka da birşey yapma tarzında yada daha modern bir ifadeyle ALL-IN-ONE bir IDE ‘ye sahip olmasak da Javacılar için de vazgeçilmez hatta yavaş yavaş standart haline gelmeye başlayan Eclipse var. (Bir kere ayarla her yerde kullan.)

Aslında bu tip bir ihtiyaç her uygulama geliştiricinin hayatında var. Yani uygulama geliştirirken herşeyin bir arada olması en azından basitçe işinizi görecek araçların tek bir yerde toplanması önemlidir.(Ciddi durumlarda Aqua Data Studio, Rapid SQL yada TOAD gibi araçlara ihtiyaç olabiliyor.) Bu nedenle Visual Studio ‘nun hakkının verilmesi gerektiğine inanıyorum.

Eclipse ‘e dönecek olursak default olarak gelen eklentilerle zaten Javacıların işini fazlasıyla görecektir ama ihtiyaçlar değiştikçe yeni eklentiler kurarak daha da zenginelştirmek gerekebilir. Bu noktada en büyük sıkıntı doğru eklentiyi seçme konusunda yaşanır. (Eclipse için yüzlerce plugin -eklenti- mevcut)

quantum2.jpg  Bitirme projem sırasında Visual Studio ‘da en sevdiğim ve sıklıkla kullandığım özelliklerden bir  tanesi de Server Explorer idi. Hatta eğer bağlantı kuracağınız sunucu yerelinizde değilse SQL  Server 2005 Management Studio ‘dan daha hızlı çalıştığını da söyleyebilirim. Bu güzel özelliği Eclipse ‘e de kazandırmak gerekli diye düşünürken karşıma Quantum DB eklentisi çıktı. JDBC tabanlı bu güzel plugin ile hem veritabanı sunucunuzda ne var ne yok visual bir şekilde görebilirsiniz hem de SQL sorgularınızı çalıştırabilirsiniz.

Quantum DB ‘yi Eclipse dahil etmek çok kolay ama burada karşınıza bir GEF (Graphical Editing Framework) plugin sorunu çıkabilir.Öncelikle Eclipse GEF ‘in doğru sürümünü eklemeli , ardından da Quantum DB kurulumuna geçmelisiniz. ( Note: Quantum needs the GEF plugin to work, so you have to install it before installing Quantum)

Eclipse ‘e plugin eklemek için ben genellikle web update ‘i tercih etmiyorum. Onun yerine plugini bilgisayarıma indirip Eclipse ‘e ekliyorum , bu sayede ileride farklı bir Eclipse ‘e de kurma şansım oluyor. (Plugin dosyalarını kopyalayıp yapıştırmak her zaman olumlu sonuçlar doğurmuyor o nedenle bu yöntem daha sağlıklı !)

Kullandığınız Eclipse sürümü için uygun GEF pluginini buradan indirebilirsin. İndirdiğiniz zip dosyasını uygun bir yere extract ettikten sonra Help -> Software Updates ->Find and Install yolunu takip edin. Search For New Futures To Install seçeneğini seçtikten sonra ilerleyin ve bir sonraki adımda New Local Site butonuna tıklayın. Açılan pencereden az önce plugini extract ettiğiniz dizini seçin ve tamam diyerek bir sonraki adıma geçin. Kullanıcı sözleşmesini de onayladıktan sonra kurulum tamamlanacaktır ve pluginin düzgün bir şekilde çalışabilmesi için Eclipse ‘i baştan başlatın.

GEF eklentisini kurduktan sonra buradan Quantum DB ‘yi indirin ve GEF ‘i kurarken izlediğiniz adımların aynısını tekrarlayın. Eğer herhangi bir hata almadıysanız Eclipse ‘i yeniden başlattıktan sonra eklentiniz kullanımıma hazır.

Window -> Open Perspective -> Other -> Qunatum DB yolunu izleyerek Quantum DB perspektifine geçebilirsiniz. Sonra da Window -> Show View yolu ile bu perspektif içerisinde görülmesini istediğiniz Quantum DB bileşenlerini seçebilirsiniz.

quan.jpg  Artık Quantum DB ‘nin görsel ayarları tamam. Tek yapmanız gereken Veritabanı          sunucunuzun çalışır halde olup olmadığını kontrol etmek ve Database Bookmarks alanına New Bookmark ile eklemek. Burada en önemli nokta uygun sürücüyü Quantum DB ‘ye göstermek. Açılan JDBC Driver penceresinden Add Driver ile veritabanı yönetim sisteminize ait sürücüyü eklemeniz gerekir. (İlgili sürücüleri kullandığınız DBMS ‘in üreticisine ait web sitesinden indirebilirsiniz.) Bir sonraki adımda da ilgili DBMS için gerekli bağlantı bilgilerini verip, bu bookmark ‘a bir ad vererek işleminizi tamamlayabilirsiniz. ( MySql için yandaki resimde örnek bir bağlantı gerçekleştirdim.)

Quantum DB ile ilgili başlangıçta sizlere lazım olacak bilgileri bu yazıda aktarmaya çalıştım. Bu güzel aracın diğer özelliklerini keşfetmek sizlere kalıyor. Fırsat buldukça farklı Eclipse pluginlerini inceleyip , deneyimlerimi sizlerle paylaşamaya çalışacağım. Şimdilik benden bu kadar . Sağlıcakla kalın…

IN ALL TEST CASES J2EE PLATFORM OUTPERFORMED .NET

Posted by İbrahim DEMİR on 27/06/2007 No comments

sunlogo.jpgÇalışma hayatına atılmam ile birlikte kendim için yaptığım işlere ayırdığım vakit de daraldı. Kendimi geliştirmek adına yeri geldiğinde günde 25-30 arasında blog yazısı yada makale okurdum. Fakat çalışma hayatı bunlara yavaş yavaş engel olmaya başladı. Ben de çözüm olarak okumayı planladığım makalelerin çıktısını alıp serviste okumaya karar verdim. İş yerim Anadolu yakasında evim ise Avrupa yakasında olduğundan yolda gün içerisinde yaklaşık 3 saatimi geçiriyorum. Bu zaman dilimi de birşeyler okumak için ideal. (Malesef Musta Abi gibi yolda video izleme lüksüne de sahip değilim :) )

Akşam eve dönerken okuduğum yazılardan bir tanesi de SUN Microsystems tarafından yapılan bir test ile ilgili. Yazının başlığı aynen şöyle: Web Services Performance Comparing Java 2 Enterprise Edition and .NET Framework.

Bu blog yazıma verdiğim başlık da testin özet bölümündeki ilk cümle.(Olayı çok güzel özetlemişler :) )  Biraz fazla iddialı bir söz de olsa test sonuçlarını aynen özetleyen bir cümle.

Kendilerince tarafsız bir test gerçekleştirmişler. Test Windows paltformunda işletim sistemine ait gereksiz servisler etkisiz hale getirilerek yapılmış. Test için de kendi yazdıkları WSTest aracını kullanmışlar. Bu araç çok basitçe tasarlanmış bir web servis test aracı. Tek yaptığı web servisinde tanımlı metodlara parametre göndererek çağrıda bulunmak ve sonucu almak. Metodlarda da hiçbir işlem yapılmıyor yani alınan değerler doğrudan geriye döndürülüyor bu sayede platformların diğer özelliklerinin Web Servis kıyaslamasındaki etkisi en aza indirilmiş.

Test ile ilgili daha fazla detay vermeye gerek yok. Test sonucuna göre J2EE paltformu .NET platfomundan 2 kat hatta yeri geldiğinde 3 kata kadar dah hızlı. Burada en önemli nokta .NET Framework 1.1 ve IIS 6.0′a karşılık Java Web Service Developer Pack 1.3+Tomcat 5.0 kullanılmış olması. Yani .NET Framework 2.0 ile web servisi konusunda ne gibi gelişmeler oldu ve perfomans konusuna bu nasıl yansır bu test ile bu konuda bilgi sahibi olma şansımız yok. (Ama Microsoft ‘un  yaptığı testte bu konu ile ilgili bilgiler mevcut. İlgili testi yazının sonunda bulabilirsiniz.)

Aslında perfomans konusunda farkı yaratan J2EE ile kullanılan JAX-RPC implementasyonu. Aman canım ne olacak ne var bir XML ‘i işlemekte deyip geçmemek gerektiğini de bir kere daha görmüş olduk. “Parsing” olayı söz konusu oldu mu fazladan koyulacak bir kontrol ifadesi bile ciddi performans kayıplarına neden olabiliyor. Hele bir de parser RECURSIVE bir algortimayla çalışıyorsa vay haline sistem kaynaklarınızın.

Bu testi sizlerle paylaşmanın asıl nedeni ise bir teknoloji ile çalışmaya karar verdiğinizde size getireceklerinin yanında sizden götüreceklerini de düşünmenizi sağlamak. Ben de bu testin elbette biraz da olsa taraflı olduğunun farkındayım. ( Aynı durum yazının sonunda bulacağınız ve Microsoft tarafından gerçekleştirilen test için de geçerli.) Asıl mevzu ise popüler teknolojilerin (WEB SERVİSİ , XML , AJAX vs.) bilinçsiz kullanıldıklarında bizlere faydandan çok zarar getireceğidir.

Fırsat buldukça servis yolculuklarım sırasında okuduğum güzel makaleleri blogumda paylaşamaya devam edeceğim. Şimdilik benden bu kadar. Sağlıcakla kalın…

KONUYLA İLGİLİ FAYDALI LİNKLER:

Sun tarafından gerçekleştirilen teste ait yazı
Microsoft tarafından gerçekleştirilen web servisi performans kıyaslaması
Mustafa TAN tarafından yazılmış konuya ilişkin çok güzel bir yazı
Web service performance checklist