Category Archives: DEVELOPMENT

UML SEMİNERİ

CETURK olarak bilişim alanındaki seminer organizasyonlarımız sürüyor.  Sibnet ile birlikte gerçekleştirdiğimiz Java ile Kurumsal Mimariler seminerinin ardından sırada UML semineri var. Semineri Netron Bilişim Akademisi ‘nden Aykut Taşdelen verecek ve Microsoft ‘un bu konudaki çözümlerine değinecek. Microsoft Türkiye Marmamara Salonu ‘nda gerçekleştireceğimiz seminerimize hepiniz davetlisiniz. Tek yapmanız gereken buradan kayıt yaptırmak.

Ayrıca seminer organizasyonlarımıza Oracle ,Silverlight ve Microsoft ‘un Expression ürün ailesi ile devam edeceğimizi de buradan sizlerle paylaşmış olayım.

Seminer ile ilgili detaylar aşağıda. Seminerde görüşmek üzere….

ETKİNLİK DETAYLARI
Etkinlik Konusu : UML (Unified Modelling Language) Semineri
Etkinlik Türü : Seminer
Hedef Kitle : Uml ile ilgilenenler
Kontenjan : 80
Etkinlik Tarihi – Saati : 10.11.2007 — 14.00 – 18.00
Süre : 1 Gün
Eğitimi Veren : Aykut TAŞDELEN
Etkinlik Yeri : Microsoft Türkiye İletişim Bilgileri
ETKINLIK IÇERİĞİ
Bu seminerde UML (Unified Modelling Language) yanı sıra Microsoft’un çok da fazla
bilinmeyen bir ürünü olan MS Visio ile örneklemeler yapılacaktır. Seminerde ele
alınacak konu başlıklarından bazıları şunlardır :
UML (Unified Modelling Language)
UML Kullanımının Getirileri
Nesne Yönelimli Tasarım
Temel Kavramlar
Use Case Diyagramları
Use Case Tanımları
Use Case’lerin Yeniden Kullanımı
Aktörlerin Türetilmesi
Arayüzler (Interface’ler)
Use Case’lerin Sınıf Tasarımında Kullanımı
Sınıf Diyagramları
Nesneler Arasındaki İlişkiler
Durum (State) Diyagramları
Aktivite (Activity) Diyagramları
Sequence Diyagramları
Deployment Diyagramları
Microsoft Visio
ETKİNLİK SPONSORUMUZ
ETKİNLİK HEDİYEMİZ
Seminere katılan 3 üyemize çekilişle aşağıdaki kitaplardan hediye edilecektir.:

Asp.Net AJAX


JIRAMANIA BİZE ÇOK UZAK ÇOOKKK!!!

threetools.pngGeçtiğimiz günlerde Atlassian firmasının sitesinde gördüğüm What 3 Dev Tools Do You Rely on Most? başlıklı haber çok hoşuma gitmişti. Yani bir uygulamanın bu kadar çok amaca hizmet edebilir olması ve bu kadar efektif kullanılması hem o uygulamayı yazanlar için hem de kullananlar için çok güzel bir durum.

Yukarıdaki resimde de görüleceği üzere arkadaşlar development süreçlerinin her aşamasına JIRA ‘yı entegre etmişler. Bu sayede JIRA+CVS+ECLIPSE üçlüsü ile projelerini tıkır tıkır yürütmeyi başarmışlar. Resme bakınca JIRAMANIA bu olsa gerek demiştim kendi kendime…

Bu arada nedir bu JIRA diyenler buradan ve Mustafa Tan ‘ın blogundan detaylı bilgiye ulaşabilirler.

JIRA özetle “Söz uçar yazı kalır” felsefesinin yazılım projelerinde hayat bulmasıdır benim gözümde. Yapılan , yapılması gereken, yapılması umulan yada yapılacak olan işlerin takip edilebilmesini ve kayıt altında olmasını sağlar JIRA. Yani e-maili, telefon yada birebir muhattabiyeti kayıt altına alır. “Abi bee bu kod patlıyor bir el atıver de biz de teste devam edelim” şeklinde gelecek vakitsiz bir telefonun önüne geçer JIRA. Onun yerine e-mailinize ve JIRA hesabınıza tatlı bir issue düşer bir öğle tatili öncesinde… :)

Açar bakarsınız ve gerekeni yaparsınız. Sonradan birisi çıkıp da “Ben şu zaman demiştim sen bu zaman yaptın“, yada “ben böyle demiştim sen şöyle yaptın“gibi bir iddiada bulunamaz çünkü herşey orada yazılmıştır. JIRA ‘nın tanıtımı yapıp , teorik olarak kullanımını anlattıktan sonra sıra geldi hayatın gerçekleriyle yüzleşmeye…

Biz de şu anda dahil olduğum projede JIRA ‘nın nimetlerinden faydalanmaya çalışıyoruz. Hem development hem de test sürecinde yoğun bir şekilde JIRA kullanılıyor. Özellikle de projesini yaptığımız şirketin IT departmanıyla olan ilişkilerde işlerin daha ciddi yürütülmesi adına JIRA köprü görevi görüyor. Şu sıralarda bizim ekibin yazdığı modüller Alfa tesinde. Müşterimizin IT departmanındaki arkadaşlar bizlerin yaptığı ekranları test edip bizlere hatalı durumlarda “issue açıyorlar“. Buraya kadar herşey olağan. Ama bazen etrafımda öyle manzaralara denk geliyorum ki… Millet uzaya gidiyor biz nereye diye düşünüyorum…

Bir hata raporlanmış, developer arkadaş da düzeltmiş bir güzel. Şimdi tek yapması gereken JIRA ‘da kendisine atanan görevi ufak bir açıklama girerek kapatmak. Developer arkadaş kaygılı. Neden mi? Çünkü hatayı raporlayan vatandaş açıklamaları anlamamkta büyük bir direnç gösteriyor. Ne yapsam ne yazsam diye düşünürken oradan dahiyane bir fikir egliyor. “Ya telefon açıp söylesene. Böyle böyle diye anlatsana” (Hani yazılandan anlamıyor belki laftan anlar diye umuyor sanırım) yada “Dur dur ben de e-mail adresi var o bayanın uzun uzun bir mail at olsun bitsin“  Güler misin ağlar mısın?

Madem bizim telefon, e-mail gibi hizmetlerimiz var neden JIRA kullanıyoruz? Neden birileri JIRA ‘da bizim sorunsuzca çalışabilmemiz için emek harcıyor? Yada bu işler madem böyle de yürütülebiliyor neden bir grup zeki arkadaş oturup JIRA adlı bir uygulama geliştiriyor. Maksat yeşillik olsun diye değil mi? Yada el alem “Sizin JIRA ‘nız var mı?” diye sorduğunda “Olmaz mı hem de en enterprise edition ‘ından” diyebilmek için…

Görüldüğü üzere bir uygulama ne kadar akıllıca tasarlanmış olursa olsun işin içine beşeri faktörler girince, o akıllıca tasarım pek bir anlam ifade. Siz siz olun bu gibi fikirlere aldırış etmeyin. Elinizdeki araçlar her ne kadar amacınız olmasa da onları ne kadar efektif ve doğru kullanırsanız o kadar rahat edersiniz. Sisteminize ekleyeceğiniz fazladan her araç hem maddi yük getirecek hem de ayrı bir yönetim süreci isteyecektir. O nedenle bu gibi işlere ayıracağınız kaynağın karşılığını en iyi şekilde almalısınız. Hem siz elinizdeki aracı doğru kullanmak konusunda ne kadar ısrarcı olursanız etrafınızdakiler de er geç size uymaya başlayacaktır. (Yani birileri derdini yazarak anlatmayı ve diğer taraf da yazılandan birşyeler anlamayı öğrenmeli.) Yanlışları değil doğruları toplu halde yapmaya özen göstermenizi dileyerek yazımı burada noktalıyorum.

SQL SERVER JDBC DRIVER 1.2 CTP

Geçtiğimiz ay Microsoft SQL Server için Type 4 özelliklerini sağlayan yeni JDBC sürücüsünün 1.2 sürümünü yayınladı. Yayınlanan bu sürücü hem SQL Server 2005 hem de 2000 sürümüyle uyumlu olarak çalışabilen bu yeni sürücü JDBC 3.0 spesifikasyonunyla tamamen uyumlu olarak hazırlanmış.

Sürücünün Type 4 özelliklerini sağlaması performans konusunda ciddi avantajlar getirecektir. Pure Java Driver yada Thin Driver denilen bu tipteki sürücüler istemcilerden (yazdığımız Java uygulamalarından) gelen JDBC çağrılarını DBMS ‘in anlayacağı şekilde network çağrılarına çevirerek veritabanına doğrudan erişim sağlar. Arada database middleware olmadığı için de diğer sürücülere göre daha hızlı çalışır. (Ne kadar az katman o kadar çok performans) Özellikle intranet uygulamalarında bu tip bir sürücüyü tercih etmek avantajlı olacaktır diye düşünüyorum.(Tabi ne kadar az katman o kadar az kontrol ?? Ondan ötürü kullanım öncesi iyi bir analiz şart.)

Bu sürücü ile uygulama geliştirmek için JDK 1.4 veya daha ileri bir sürümünün makinanızda kurulu olması gerekiyor. Yapılan açıklamalara göre BEA WebLogic, IBM WebSphere, JBoss, and SunBu gibi uygulama sunucuları ile sürücünün sorunsuzca çalıştığı görülmüş. Ama her Microsoft ürününe olduğu gibi bu sürücüye de şüpheyle yaklaşıp kendim de denedim ve ben de SQL Server 2005 Enterprise Edition üzerinde önceden yazdığım ufak uygulamayı sorunsuzca çalıştırdım . Fakat bu herşeyin yolunda olduğu anlamına gelmiyor elbette. Bu adresteki gibi stored proc. içerisinde geçici tablo kullandıklarında sorun yaşayanlar da var. (Final sürümüne ulaşmadan kritik uygulamalarda Mcirosoft ürünlerini kullanmayı Microsoft çalışanları da tavsiye etmiyorlar.)

Bu ücretsiz sürücü ile sağlanan Adaptive Buffering ve SSL Encription gibi özelliklerden uygulamalarınızda faydalanmak isterseniz mutlaka bir test sürüşü yapmalısınız. Adaptive Buffering özelliği sayesinde büyük boyutlu verilerle yaşadığınız performans darboğazlarını aşabilme şansınız var.

Aslında JDBC Type 4 sürücülere çoğumuz büyük umutlar bağlamıştık ama nedense DBMS üreticileri bu konuda beklenen çevikliği gösteremediler. Fakat Microsoft herkesten hızlı davranıp Type 4 sürücüsünü herkesten önce çıkarmıştı. Hatta JDBC-TR mail grubunda bunun önemli bir şirket stratejisi olduğunu daha doğru güzel bir Microsoft Uyanıklığı örneği olduğunu konuşmuştuk.

Yazının sonuna Type 4 sürücülerle ilgili iki tane kısa ve öz yazıyı ekledim. Özellikle de devx.com ‘daki yazıya göz atmanız sürücü seçimi sırasında doğru kararı almanızda faydalı olacaktır.

Şimdilik benden bu kadar. Yaşadığım bir dolu aksilikten sonra blogumu güncellemeye kaldığım yerden devam ediyorum. İlerleyen zamanlarda özellikle de üzerinde çalıştığım Test Driven Development ve Unit Testing konularında keyifli paylaşımlarda bulunmaya çalışacağım.

Types of JDBC technology drivers
JDBC Drivers: How Do You Know What You Need?
Microsoft SQL Server 2005 JDBC Driver 1.2 Community Technology Preview August 2007

UNIT TESTING & TDD (Test Driven Development)

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?