engin güller

We are using Clearcase as source control management, Clarify CRM as issue tracking system in company. We are writing code mostly in eclipse and making builds with ant.  We have made  a what if scenario last week in company.  What can we use instead of Clearcase and Clarify CRM is there any good eclipse and ant alternatives. Code review is also vital for us. We are using a in house developed code review tool. It is tightly integrated with clearcase. Developer add activity ids and send review request to architect, architect add comments etc finally architect approve code changes when everything is ok. Finally developer merge changes.

Issue Tracking Tools

Trac
Trac is a web based project management system, it simple and easy to use. Trac is written in Python. I had a bit hard time while installing trac but if I can install everybody can so I will not say “installation is hard, it is minus for trac”.
Trac does not support multiple project directly and it is important for us. I have learnt that people solved this problem by adding some custom code to trac. But adding custom code needs developer to write and somebody maintain it for this reason I found it a drawback of trac.
Subversion integration of trac is very good. Integrated wiki also great actually trac’s itself is a wiki. We are using Opentext’s LiveLink for document management. Actually we are writing design documents, feature documents in Microsoft Word and we are keeping them in LiveLink. Writing all design documents in wiki would be great for us because you can make links to issues or subversion commits in your wiki too. Making search in a wiki (html) is more effective than making search in lots of word documents. You can not make link from a word document to some page of another word document. Making all of these are very easy with html so with trac’s wiki.
Trac has also plugin api. You can extend trac by plugins. There are a lot of trac plugin. Some of them still under development. Stable ones become a part of main trac distribution.
I have read lots of comments about trac and a common opinion for trac is, trac is best for small size projects. I don’t know why but maybe trac does not scale well when project size increased. We are more than one hundred developer.

Bugzilla
Bugzilla is developed by Mozilla Foundation. Eclipse project, Apache Foundation (moving JIRA) and Mozilla Foundation (creator of Firefox and Thunderbird …) are notable users of Bugzilla.  Bugzilla is developed since 1998 so it very mature and robust issue tracking tool. Bugzilla does not have integrated wiki or source control explorer like trac. Bugzilla is just a bug tracker but good one.  You can integrate Bugzilla with subversion by using SCM Bug. I have tried SCM Bug and it worked well. You can link subversion commit with a Bugzilla issue if you setup SCM Bug. Commit comments and changes goes under issue as comment in Bugzilla. I have liked Bugzilla its user interface is a bit weird but who cares, you can integrate Bugzilla with eclipse by using Mylyn plugin you don’t need to open Bugzilla user interface.

JIRA
Atlassian JIRA is awesome. It is highly customizable, you can easily create a new workflow which satisfies your needs. JIRA is free for open source projects (JIRA cathed a great momentum by this decision) you have to pay for commercial needs. It is 8000$ annually for +100 developer but I did not found it high. It seems we need some custom development to satisfy our needs with Trac or Bugzilla. We have to hire someone for this or we have to do it ourself but I am sure it will cost more than 8000$ to modify and maintain Bugzilla and Trac. Atlassian also has other tools which integrates well with JIRA. For example Confluence for document management, wiki etc. Crubicle for code review. It is another plus for JIRA.

My choice:

1. JIRA
2. Bugzilla
3. Trac

I will continue survey in Part-2. Version Control, IDE and Build Tools are subject of Part-2.

Bir programcı ve bir mühendis uzun bir uçak yolculuğunda yan yana oturuyorlarmış. Programcı mühendise eğlenceli bir oyun oynamak ister misin diye sormuş? Mühendis uyumak istediği için programcının teklifini kibarca redditmiş ve dönüp uyumaya çalışmış. Programcı oyunun çok eğlenceli olduğunu söylemiş oynamaları konusunda ısrar etmiş ve oyunun kurallarını açıklamaya başlamış.
“Sana bir soru soracağım eğer bilemezsin bana 5$ vereceksin, daha sonra sen bana soracaksın ben bilemezsem sana 5$ ödeyeceğim.” Mühendis teklifi tekrar kibarca redditmiş ve tekrar uyumaya çalışmış. Programcı ısrar etmiş “Peki sen soruyu bilemezsen bana 5$ ver eğer ben bilemezsem sana 50$ vereceğim demiş.” Bu teklif mühendisin dikkatini çekmiş ve oyunu oynamadan programcıdan kurtulamayacığını anlamış ve oyunu oynamayı kabul etmiş. İlk soruyu programcı sormuş
“Dünya ile ay arasındaki uzaklık nedir ?”
Mühendis hiç cevap vermeden cüzdanından 5$ çıkarıp programcıya vermiş. Soru sorma sırası mühendise gelmiş.
“Bir yokuşa üç bacak ile çıkıp dört bacak ile inen şey nedir?” diye sormuş mühendis.
Programcı bilgisayarını çıkarıp internete bağlanmış ve sorunun cevabını aramış. İnternet üzerinden kütüphanede arama yapmış yine bulamamış arkadaşlarına mail atmış fakat bir cevap bulamamış. Bir saatlik bir uğraş sonucu pes etmiş ve mühendise 50$ vermiş.
Mühendis 50$ almış ve uyumaya devam etmiş. Programcı duruma bozulmuş ve mühendisi uyandırıp “Peki sorunun cevabı neydi ?” diye sormuş.
Mühendis cebinden 5$ daha çıkarıp programcıya vermiş ve uykusuna kaldığı yerden devam etmiş.

Bir yazilim projesinde zaman planlamasi yapmak zor bir istir, fakat hala çogu firma bu zaman planlamalarina dayanarak projelerini yürütmeye devam ederler. Bu yazida yazilim projelerinde yapilan zaman planlamalarinda yapilan en temel 12 hataya dikkat çekmeye çalisacagim.

1. Bilinmeyen üzerine plan yapmak imkansizdir

Çogu yazilim birbirinden farklidir, ve her projede neredeyse daha önce hiç yapilmamis bir ürün gelistirilir. Projede yapilacaklar belirli olsa bile, karmasik bir sistemi gelistirmek istenen belli olmasina ragmen bile zordur.
Bir program bir çok farkli yöntem ile yapilabilir. Zaman planlamasi asamasinda net olarak belirlenemeyen dizayn seçimleri, bir yazilimin bitis zamanini dogrudan etkiler.
Yapilan zaman planlarinin, istenildigi sekilde yürüyebilmesi için kabul görmüs belli basli yöntemler vardir fakat, en iyi yöntemle bile yapilan plan, yazilim gelistirme aktif olarak baslamadigi için öngörü ve varsayimdan ibarettir.

2. Yapilan Planlar Genelde Iyimserdir

Çogu programci planlarini oldukça iyimser varsayimlar üzerine yapar. Proje basladiginda daha üretken olacaklarini düsündüklerinden veya projenin karmasikligini tam olarak anlayamadiklarindan iyimser varsayimlarda bulunmus olabilirler. Bu planlari degerlendiren kisiler genelde bu iyimser planlamari biraz daha genisletip daha gerçekçi hale getirirler. Örnegin kodun yazilmasi bir haftada biter gibi bir tahminde bulunulmussa bunu 2 hafta veya bir aya çikarmakla daha gerçekçi planlar elde edilebilir.

3. Verilen Zaman Sonuna Kadar Kullanilir

Çogu programci verilen zamani sonuna kadar kullanmaya meyillidir. Yaptiklari isi erken bitirseler bile, kalani zamani projeye katkisi olmayacak kod düzeltmeleri yapmak, kodu birazcik hizlandirmak için harcarlar. Bazende isini bitirdikten sonra verilen zamanin bitmesini bekleyip farkli bir ise baslamazlar. Bu yaklasimla isler asla planlandigindan çabuk bitmez, ya saydigim nedenlerden ötürü zamaninda biter, ya da isler yolunda gitmez ve gecikir.

4. Firmalar Zaman Planlamarina Oldukça Fazla Itimat Eder

Ürün çikis tarihleri, fuarlara katilim ve tanitim tarihleri hepsi projenin zaman planmasi baz alinarak yapilir. Satis ve pazarlama birimleri anlasmalarini bu tahminler üzerine yapar ve yapilan planlamada olusacak bir gecikme daha baska yapilan bir çok planinda gecikmesine neden olur.

5. Önrülemeyen Seyler Üzerine Çok Fazla Zaman Harcanir

Yapilan tahminler mükemmel bile olsalar, proje üzerinde çalisirken karsimiza öngöremedigimiz bir çok problem çikar. Eski versiyonlarda problemler çikar bunlari düzelmek için kaynak ayirmamiz gerekir, çalisanimiz hastalanmis olabilir, proje esnasinda bekledigimiz yeni isler çikmis olabilir. Çogu sirket planlarini yaparken bu gibi durumlar için ekstra zaman ayirir, fakat varsayimlar üzerine yapilmis bir plana varsayimlar üzerine ekstra zaman eklemekle nekadar güvenilir birsey elde etmis oluruz ?

6. Zaman Planlamasina Tahmi Gözüyle Bakilmamasi

Yapilan zaman planlari aslinda bir tür tahmindir fakat insanlar buna tahmin gözüyle bakmazlar, bu planlara kesinlikle aksamayacak gerçeklesecek gözüyle bakilir ve baska planlarda buna güvenerek yapilir. Ilk planda olacak bir gecikme bu yüzden zincir etkisiyle diger planlari da etkiler.

7. Programcilar Arasindaki Verimlilik Farklari Gözardi Edilir

Bu durum yapilan zaman planlamarini daha da zorlastirir. Insaat sektöründe duvar ustalarinin ortalama bir duvari örme hizini bilebilirsiniz fakat bir isi yapma hizi programcilar arasinda çok büyük farklilik gösterir. Is yapma hizi ve bir isin bitmesi için gerek efor: bu iki bilinmeyeni kullanarak tahmin yapmaya çalistiginiz da isiniz daha da zorlasir.
Programci kendi yapacagi isin zaman planlamasini kendi yaptiginda isiniz az da olsa kolaylasir çünkü kendi üretkenlikleri hakkinda sizden daha çok bilgileri vardir. Fakat bu tahminleri onlar yerine genelde proje yöneticileri yapar ve bütün programcilara esit üretkenlikteymisler gibi davranir.

8. Müsterinin Isteklerindeki Degisiklik Proje Planina Yansitilmaz

Proje devam ederken, ortaya ufak ufak birseyler çikmaya basladiginda müsteri ortaya çikan bazi özelliklerden memnun olmaz degistirtmek ister veya memnun kalir ve ekstra bir kaç sey daha eklenmesini ister. Bu gibi degisiklikler proje planina bazen yansitilmaz fakat her gelen istek yapilacak fazladan is oldugu için bu gibi durumlar plana yansitilmak zorundadir.

9. Gerçek Anlasildiginda Genelde Çok Geç Kalinmistir

Önceki maddelerde belirtmistik programcilar genelde iyimser tahminlerde bulunurlar. Çogu zaman iyimser tahminde bulunduklarina ve projeyi yetistiremeyeceklerine inanmazlar taa ki son gün gelipte daha yapilacak bir çok isin kaldigi anlasilincaya kadar. Fakat artik çok geç kalinmistir, proje gecikmis ürün çikis tarihi ertelenmistir.

10. Bir Plan Geciktiginde Digerleri de Güncellenmeli

Programcilar genelde projenin planlanan bir kismini zamaninda bitiremediklerinde, diger yapacaklari islerin planlarini güncellemezler. Arada kaybolan zamani sonraki isleri daha hizlari yaparak kapatacaklarina inanirlar fakat genelde tam tersi. Böyle bir durum genelde iyimser tahmin yapildiginda isarettir

11. Planlar Gerçeklesmediginde Programcilar Suçlanir

Planlar geciktiginde suçlanacak birileri bulunmaya çalisilir ve bu genelde plana ayak uyduramayan programcilar olur. Bu stresli bir çalisma ortami yaratir ve programci sonraki projelerde suçlanmamak için yaptigi zaman planlamarinda genis davranir.

12. Planlari Yanlis Insanlar Yapar

Programcilar üzerinde çalistiklari konuyla ilgili tahminleri kendileri yapmalilar. Proje yöneticisi bu tahmini onun yerind yaptigi zaman zamanlama konusunda sikintilar yasanir. Eger çalistiginiz yerde MBA yapmis biri sizin yerinize çalistiginiz is üzerinde plan yapiyor ise orada durmayin

12 Problems With Software Estimation yazisinin çevirisidir.

George Westinghouse bir teorisyen değildi fakat 1800′lerin en büyük mucitlerindendi. En büyük icadı raylı sistemlerde kullanılan havalı frendir.
Bu yazıda Westinghouse’ın fikirleri ve bilgisayar bilimlerine yapmış olabileceği katkılar üzerinde duracağız.

Tren Frenleri

Atlar tarafından çekilen Wagonways isimli ilk tren 1550′lerde Almanlar tarafından kullanıldı. 1804 yılında Richard Trevithick buharlı tren ile 9 mil boyunca 10 ton demir ve 70 adam taşıdı. Bu kısa yolculuk modern trenlerin başlangıcıydı.

Read the rest of this entry »

Encapsulation
Do not expose class variables, instead of doing this, use setter and getter methods and keep class variables private.

public class Car {
   private int price;
   private int maxSpeed;
   public int getPrice() {
      return price;
   }
   public void setPrice(int price) {
      this.price = price;
   }
   public int getMaxSpeed() {
      return maxSpeed;
   }
   public void setMaxSpeed(int maxSpeed) {
      this.maxSpeed = maxSpeed;
   }
}

What is the advantage of previous usage, first of all flexibility. For example you have changed your mind, decide to keep max speed read only. So we can just remove setMaxSpeed method or change it to private for internal use.
Another advantage is validation, if user want to set negative value for car price, so you can add a validation in setPrice that is it.

Is-A and Has-A Relationship
So, Ferrari is a Car, Cow is an animal lets codify these statements.
Read the rest of this entry »