Category Archives: BİLGİSAYAR MÜH.

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

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?

İŞLEMİNİZ BAŞARIYLA TAMAMLANMIŞTIR ?

Bir uygulamadan duyacağınız en güzel cümledir “İşleminiz BaÅŸarıyla Tamamlanmıştır” cümlesi fakat bu güzel cümle bazen sizi çok kötü biçimde aldatıyor olabilir.Geçen hafta başıma bu tip bir olay geldi ve ben de sizlerle paylaÅŸmak istedim.

Geliştirmekle sorumlu olduğum modülün düzgün bir şekilde çalışıp çalışmadığını anlamak için öncelikle farklı tablolardan bazı verileri alıp bir look-up table oluşturmam gerekiyordu. (Select sorgusundan istediğim kritelere uygun verileri çekip look-up tabloma ekleyecektim.) Bunun için de verileri alacağım tabloları uygun verilerle doldurmam gerekti. Ben de tablo doldurma işini SQL cümleleriyle değil de o tablolara kayıt ekleyen ekranları kullanarak yapmaya karar verdim. Hem böylelikle arkadaşlarımın yaptığı ekranları da test etmiş olacaktım. (Ayrıca tablolar arasında PK-FK ilişkisi olduğundan veritabanı bütünlüğünün bozulmaması için verileri bu şekilde girmek daha sağlıklı olacaktır diye düşündüm)

Öğle aramı bu iÅŸ için ayırıp 58 tane kayıt girdim. (Yani en azından ben öyle sanıyordum.) Sonra bir güzel ADS ‘yi (Aqua Data Studio) açıp master tabloya select count … diyerekten sorgumu yolladım ve gördüm ki ben 58 tane kayıt girmek için öğle aramı heba etmeme raÄŸmen tabloda sadece 22 tane kayıt vardı. (Bir an yorgunluktan kaydet butonuna basmadığımdan bile şüphelendim) Sonra 10 tane daha kayıt girdim ve gördüm ki kayıt sayısı 27 olmuÅŸ. O zaman anladım ki bir yerlerde “insert” yerine “update” yapılıyordu. Olmayan bir kaydın neyini update ediyordu peki? Cevap basit kaydı aradığımız kriter yanlıştı ve ne ilginçtir ki tabloda o yanlış kritere uyan kayıtlar vardı.

Ufak bir debug operasyonundan sonra hatayı bulup düzelttik. (Tesadüfen bulduk ama olsun) Yine ne ilginçtir ki bu ekranın testi de yapılmıştı. Yani Test-Case ‘leri “genelde “Kullanıcı saçma sapan birÅŸeyler yapınca ne olur” ÅŸeklinde olduÄŸundan bu hata gözden kaçmıştı.

Sanırım bu yanılgıya çoÄŸu uygulama geliÅŸtirici (ben de dahil olmak üzere) düşüyor. Yani yeterince Exception-handling yaptıysak ve kendimize de birazcık güveniyorsak “İşleminiz BaÅŸarıyla Tamamlanmıştır” mesajına hemen kanı veriyoruz. Bu yapımızdan ötürü de bu tip SİNSİ hatalar gözümüzden kaçıveriyor.

Okuldaki projeler sırasında da bu tip hatalar başıma geldiğinden veritabanına kayıt atarken mutlaka attığım kayıtları kontrol ederim. Hem ekran ile veritabanındaki tablolar arasındaki boyut kısıtlamalarının uyumunu kontrol etmek hem de beklediğim kayıtların gerçekten BAŞARIYLA kaydedildiğini görmek için. Aksi halde uygulamayı geliştirdiğiniz sırada yapmış oladuğunuz mantık hatalarını kolay kolay görmeniz mümkün olmuyor. Hem bu tip hatalarda bir hata mesajı yada anormallik olmadığından Production ortamında da o modülü kullanan son kullanıcının bir şikayeti olmuyor. (Taaki bir gün kaydettiği verileri görmesi gerekinceye kadar)

Öğle arama mal olan bu olaydan en azından testler sırasında daha dikkatli olunması gerektiÄŸini öğrenmiÅŸ oldum. (Normal ÅŸartlarda testlerin , görevi yazılım test etmek olan kiÅŸilerce yapılması gerekir??) GeliÅŸtirdiÄŸiniz uygulamaları test ederken “Umarım bir hata mesajı almam da bir an evvel yemeÄŸe giderim” mantığından uzak durmanızı tavsiye ediyorum aksi halde ilerliyen zamanlarda uzun süre aç kalabilirsiniz. Åžimdilik benden bu kadar. SaÄŸlıcakla kalın…

[SOA]CILAR ve [ANTI-SOA]CILAR

soa.jpg

GeçtiÄŸimiz hafta Cumartesi günü IBM ve Ceturk iÅŸ birliÄŸi ile keyifli bir SOA semineri düzenlemiÅŸtik. Seminere ait sunumu indirmek için Arden AGOPYAN ‘ın blogunu ziyaret edebilirsiniz. Bu yazıyı da sadece seminer sunumunu paylaÅŸmak için yazacaktım ama konuyu bu kadar yüzeysel bırakmaya içim el vermedi.

SOA ‘ya karşı olan ilgim ben daha öğrenciyken okulumzda gerçekleÅŸtirilen Ulusal Yazılım Mimarileri Konferansı ‘a katıldığım bir sunumda baÅŸlamıştı. (Daha öğrenciyken dediÄŸime bakmayın çok uzun zaman olmadı öğrenciliÄŸimi sonlandıralı.) KonuÅŸmacı olarak gelen kiÅŸi (Prof Dr. M. Naci Akkök) her ne kadar Oracle çalışanı (Chief Architect) olsa da seminer boyunca sık sık IBM ‘den ve SOA ile IBM arasındaki baÄŸdan bahsetti durdu. Bir Oracle çalışanının bu kadar çok IBM ‘den bahsetmesi garibime gitmiÅŸti açıkcası. (Bu arada seminerin konusu: “A Practical and Methodical Interpretation of the Service-Oriented Architecture” idi)

Zamanla iÅŸin içine girdikçe IBM ‘in SOA alanındaki çalışmalarına ben de ÅŸahit oldum. Oracle adına bizlere SOA anlatmaya gelen kiÅŸi Oracle ‘ın bu alandaki ürünlerden ve SOA yaklaşımından da bahsetmiÅŸti ve o zamanlar anlattığı konuları anlamak bir hayli güçtü benim için. (Sadece benim için deÄŸil ÅŸu anki patronum Semih Çetin için de anlatılanlarda gariplikler ve anlaşılması güç noktalar vardı ki kendisi de sık sık sunumu bölüp hararetli sorular sormuÅŸtu.) Sunumda binlerce parçadan oluÅŸan bir sisteme ait bir resim gösterildi ve SOA budur dendi. (Resimdeki parçaları seminerden 2 saat sonra yavaÅŸ yavaÅŸ çözmeye baÅŸlamıştım.) Güya iÅŸ akışını ve süreçleri basitleÅŸtiren SOA , o resmi gördükten sonra bana çok karmaşık birÅŸeymiÅŸ gibi gelmiÅŸti.

Åžimdilerde ise dahil olduÄŸum projede Servis Yönelimli Mimari ‘yi (Service Oriented Architecture) elimizden geldiÄŸince uygulamaya çalışıyoruz ve böylesine büyük bir projede ciddi manada faydasını görüyoruz. Hatta bazen tembellik edip “Kesin bunun servisini birisi yazmıştır” diyerekten ilgili iÅŸlemi yapacak servisi bulma çabasına giriyoruz. (Aslında tembellikten deÄŸil sadece projedeki kod tekrarını önlemek için) Yada baÅŸka birisinin üzerinde çalıştığı modül ile ilgili iÅŸlem yapmamız gerekiyorsa kendisine ihtiyacımızı anlatıp bize bir servis yazmasını istiyoruz (Yani gidip yüzlerce sayfalık o modüle ait dokümanı oturup okumuyoruz) Kısacası biz SOA ‘yı seviyoruz ve kullanıyoruz.

Fakat bunlar benim kiÅŸisel görüşlerim. Yani bir yandan birileri SOA ‘ya hayranlık duyarken birileri de SOA Facts yazısındaki gibi iÅŸin dalgasını geçebiliyor. Sanırım her yeni teknoloji (Hatta SOA ‘nın yeni bir yaklaşım olup olmadığı konusunda da tartışmalar var ) bizlere kutuplaÅŸmak için bahane oluyor. Kim o teknolojiyi adam gibi kullanmayı becerebiliyorsa onu yerlere göklere sığdıramıyor ve ondan bir “SILVER BULLET” gibi bahsediyor. Bu kadar çok fanatiklikten rahatsız olanlar da hemen karşıt bir cephe oluÅŸturuyorlar. Anlayacağınız ÅŸu anda ciddi bir SOA ve ANTI-SOA kutuplaÅŸması yaÅŸanıyor.

Burada suçlu olan elbette teknoloji deÄŸil. Yani birileri onu efektif bir ÅŸekilde kullanamıyorsa yada kullanmaması gereken bir durumda kullanmaya kalkıyorsa ve baÅŸarısız oluyorsa burada suç tamamen o kiÅŸe aittir. Öte yandan her zaman yaptığımız gibi SOA ‘yı ölümsüzlüğün formülü olarak görmeyi de doÄŸru bulmuyorum. Hele de Yazılım MühendisliÄŸi gibi bir alanda birÅŸeyleri bu kadar sıkı savunmak bana pek de akıllıca gelmiyor. (Tabi bu iÅŸten para kazanıyorsanız durum deÄŸiÅŸir ??) Yazılım MühendisliÄŸi anlanında “iÅŸte en iyisi budur” denen kavramlar bir süre sonra herÅŸeyin suçlusu olarak gösterilebiliyor. Bu kadar çok kavramın türemesini bazı kiÅŸiler Yazılım MühendisliÄŸi ‘nin sürekli geliÅŸiyor olması ÅŸeklinde yorumlarken bazıları da Yazılım MühendisliÄŸi alanının yeterince olgunlaÅŸmamış olması ÅŸeklinde yorumluyor.

Bir önceki paragrafta SOA ‘nın efektif bir ÅŸekilde kullanılamamasından bahsetmiÅŸtim. Burada sanırım gözden kaçan en önemli nokta her teknolojinin her iÅŸ modeline uygun olmadığı noktası.. Hatta seminerde Arden SOA mimarisine geçmek isteyen ÅŸirketlerin önce iÅŸ süreçlerini incelediklerini ve gerekli deÄŸiÅŸiklikleri yaptıktan sonra SOA altyapısını oturttuklarını belirtmiÅŸti. Bu alanda yatırım yapmanın ciddi bir maliyeti olduÄŸundan , adam akıllı bir geri dönüş alabilmek için iÅŸi kuralına uygun yapmakta fayda var. Yine bizlerin ÅŸirket içinde biribirimizden servis istediÄŸinden bahsetmiÅŸtim. Burada da en önemli nokta TAKIM ÇALIÅžMASI. EÄŸer ÅŸirket içi iletiÅŸim zayıfsa oluÅŸturulan servis havuzu efektif bir ÅŸekilde kullanılamaycaktır.

SOA ile ilgili görüşlerimi belirttikten sonra şimdi size soruyorum siz hangi cephedesiniz? SOA mı ANTI-SOA mı ?

SaÄŸlıcakla kalın…

Konuyla ilgili linkler:

SOA Hakkında Herşey
What is SOA, really?
Service Architecture – SOA
SOA From a Corporate Perspective
IBM Developerworks – SOA

NOT: Seminerden sonra bana enteresan e-postalar gönderen arkadaşlar için ek açıklama:

*SOA bir uygulama deÄŸildir.
*IBM ‘in SOA adlı bir ürünü yoktur.
*Haliyle SOA ‘nin Crack ‘i de yoktur.
*SOA bir ürün değildir ve haliyle SOA.exe diye de birşey mevcut değildir.
*SOA web servisi demek deÄŸildir ,web servisi de SOA demek deÄŸildir.

SQL SERVER 2005 ‘DE FILLFACTOR KAVRAMI

sqlserver.jpgBlogumdaki SQL Server 2005 ile ilgili önceki yazılarımda SQL Server Storage Engine ‘in biraz sorunlu olduÄŸundan bahsetmiÅŸtim. Hal böyle olunca verilerimizi SQL Server üzerinde tutarken daha da dikkatli olmamız gerekiyor. Ben de bu konuda dikkat etmeniz gereken noktalardan bir kaçına deÄŸinmeye karar verdim.

SQL Server verileri diskten EXTENT dediğimiz formatta okur ve yazar . (the smallest unit of data that SQL Server can allocate is 64 KB) Extent ise bünyesinde 8 tane Page barındırır. Windows işletim sistemi ortamında 8*Page_Size=64K eder (İşletim Sistemleri dersini alan arkdaşların kulaklarını da çınlatmış olduk) ki bu da diskten bir defada okunabilecek veri boyutuna denk gelir.

Fillfactor kavramı ise verilerin page üzerinde ne kadarlık bir alanı kaplayacağını belirler. Yani veritabanı yönetim sisteminiz bir page ‘in ne kadarlık kısmını (yüzde olarak 1..100 aralığında) dolduracak ne kadarlık kısmını boÅŸ bırakacak bunu belirleyen parametredir. Fillfactor deÄŸeri index oluÅŸturulurken veya rebuild edilirken karar verilen bir deÄŸerdir. Mesela indeks oluÅŸtururken 70 ‘lik bir fillfactor deÄŸeri belirlediÄŸinizde page üzerinde yüzde 30 ‘luk bir alan sonradan eklenecek veriler için ayrılmış olacaktır. Burada dikkat edilmesi gereken en önemli nokta fillfactor deÄŸerini 100 vermek ile 0 (sıfır) vermek arasında bir fark olmadığıdır. Fillfactor deÄŸerleri 1-100 arasındadır o nedenle 0(sıfır) verdiÄŸinizde bu 100 olarak kabul edilir ve tüm page doldurulur.

Gelelim bu kavramların önemine: EÄŸer veritabanınızdaki okuma sayısı fazla ise bu deÄŸerin yüksek olması çok önemli yani 100 seviyesinde olması en ideali (Zaten server bazında default deÄŸer 100 ) ama okuma iÅŸlemlerinin yanı sıra sıklıkla veri ekleme ve güncelleme (yazma) da yapıyorsanız böyle zamanlarda PAGE SPLIT dediÄŸimiz vakit kaybettirici bir durumla karşılaÅŸmanıza neden olabilir.(Elbette kaybettiÄŸiniz vakti anlamanız o kadar kolay deÄŸil) Nasıl ki multi-threading yapabilen bir iÅŸletim sistemi CPU ‘da processleri çalıştırırken context-switching yapıyorsa (İşletim Sistemleri dersini alan arkadaÅŸların kulaklarını bir kez daha  çınlatmış oldum) aynı durum veriler okunurken ve yazılarken de geçerli. Tam dolu bir page’de sorgulama yaptığınızda aradığın verinin o page içerisinde olma olasılığı daha fazla olur. Öte yandan tam dolu bir page ‘e yazmaya kaltığınızda dolu olduÄŸu için diÄŸer page ‘e geçilir (Page Split) ve page split iÅŸlemi sırasındaki hesaplamalar vakit kaybına neden olur.

Tablolarınızın fillfactor bilgilerini incelemek için SQL Server üzerinde dbcc showcontig komutundan faydalanabilirsiniz. Aşağıdaki örnekte Northwind veritabanınki Categories tablosuna ait bilgiler çağırılmıştır:

use Northwind

go
dbcc showcontig (Categories) with tableresults  (tableresults parametresi seçimliktir)

*Pages Scanned:1 Extent ‘i aşıyor mu aÅŸmıyor mu görmenizi saÄŸlar
*Extent Switches: 1 ise switch var demektir (tehlikeli bir durum :) )
*Scan Density: Düşükse indeksleri yeniden oluşturmak faydalı olabilir (ALTER INDEX REBUILD )
*Avg Page Density: Bu bilgi aracılığıyla pagelerin doluluk oranları hakında bilgi sahibi olabilirsiniz.

Fill factor kullanarak index oluşturmak isterseniz de aşağıdaki örnek size yol gösterebilir:

CREATE CLUSTERED INDEX deneme_indx ON my_table (col1, col2) WITH FILLFACTOR = 50 

Yazımı bitirmeden evvel neden bu konuyu bloguma taşığıma da deÄŸineyim. JDBC_TR mail grubumuzda arkadaşım Emrah Åžeker yapacağı proje için performanslı bir DBMS arayışına girmiÅŸti ve ona cevap verirken Flickr ‘ın altyapısını anlatan bir sunumda bahsi geçen yazma ve okuma deÄŸerlerinin oranına deÄŸindim. (Kullanıcılar her 14 okumya (select) karşılık 1 yazma (insert,delete,update) yapılıyorlarmış) Yani aldığınız bir DBMS ‘i default deÄŸerlerle kullanmak her zaman akıllıca olmuyor. İşinizi ve kullanıcılarınızı iyi analiz etmek gerekir diye düşünüyorum. Yine aynı ÅŸekilde perfomans sorunlarını çözerken olayları donanım güncellemeleri ile ölçeklemeye kalkmak her zaman beklenen sonuçları doÄŸurmayacaktır. Diyorsanız ki kim bu kadar detaylı ÅŸeylere dikkat ediyor? Ben de diyorum ki Dikkat Eden Kazanır!

Åžimdilik benden bu kadar saÄŸlıcakla kalın…

-Tavsiye-
Who Cares about FillFactor?
SQL Server 2005 Books On-Line
Understanding SQL Server’s DBCC SHOWCONTIGÂ

NOT: Yukarıda bahsi geçen konu diÄŸer DBMS ‘leri kapsayacağı gibi kapsamaya da bilir. O nedenle bu yazıyı sadece bilgi sahibi olduÄŸum SQL Server ‘i örnekleyerek yazdım.