İş Görüşmelerinden - Sürrealizmin Doruklarında - #1

Bir keresinde büyük bir IT firmasıyla iş görüşmesine girmeden önce kağıda SQL ve Java kodu yazmam istenmişti. Yazılımcının kağıt üzerine kod yazmasının bir benzeri, edebiyatçının çekiç ve çiviyle duvara hiyeroglif yazması olsa gerek. Yine aynı görüşmede beni sınayan cingöz mühendis:

- Peki design pattern'lar?

sorusunu patlatırken, o zamanlar halen "buzz"ını koruyan bu kavramı dağarcığından akıtmanın zevkini burun kanatlarını titreterek yaşıyordu. Sorunun genelliği ve anlamsızlığı karşısında afallayan ben:

- Hangisi?

bile diyemeyecek bir tutulma yaşamıştım. Hangi koşullarda? Hangi sorun için? Kimin design pattern'ı?

Sanatı sorunun içinde çözüm üretmek, hatta bunu bazen zevk için yapmak olan mühendisin kabiliyetini buna benzer sığ yöntemlerle ölçmeye çalışan insan kaynakları personeline birer kaynak makinası hediye etmek istiyorum. Bir sanat öğrenmek isteyen insan kaynakçıları bu makinayla en yakın kaynak ustasına başvurabilirler. İşinin hakkını veren sanatçı insan kaynakçıları müstesna...

İş görüşmesi maceralarımı paylaşmaya ilerleyen günlerde devam edeceğim. Açık yazılım serisinin 3'üncü bölümü ise yarın karşınızda olacak; biraz özleyin istedim.

Open Source for the Enterprise - Ya Da - Bazıları Olgun Sever - Bölüm 2

Evet, bazıları olgun sever. Açık yazılımın olgunluğu daha fazla döküman ve online bilgi, daha az bug ve daha çeşitli platform için destek ve uyumluluk anlamına geliyor. Peki açık yazılımın olgunluğu nasıl anlaşılır? Bu sorunun cevabını yine kullanıcı bulmak zorunda. Kitabın bu bölümü bu soruya sağlıklı bir cevap bulmanın yönetimi anlatıyor.

Açık Yazılımın Tuzakları

Açık yazılım seçiminde yapılacak hataların hazin sonuçları:

• Beklenenden daha fazla emek ve zaman istiyor
• Kullanılan sistemle uyumsuz
• Yazılımı geliştiren ekipten veya community'den destek almak imkansız

Yukarıdaki durumlara düşmek istiyorsanız, çok zekisiniz tebrik ediyorum, şu listedekileri eyleme koyunuz:

1. IT departmanınızın seçtiğiniz açık yazılımla ilgili deneyimi ve bilgisi olmasın.
2. Community desteği bulunmayan açık yazılımları seçmeye özen gösterin. Örneğin projenin forumuna en son post Mart 2002'de yapılmış olsun.
3. Projenin adı çok fazla duyuluyor diye, sadece popülaritesine bakarak seçim yapın.
4. Lisansında sorun olan, ticari babalarla başı belada olan projeleri tercih edin.
5. Projenin daha olgunlaşmadan yavaşlamış olmasına dikkat edin. En son bug-fix seneler önce yapılmış olsun.
6. Kullandığınız platform için uygun olmayan açık yazılımı tercih edin. Örneğin MS IIS, Oracle ve Solaris kullanıyorsanız Apache, MySQL ve Linux için yazılmış projelere yönelin.

"Yok, hayır, istemem, istediklerim aksi yöndedir" diyorsanız, buyrun size olgunluğu belirleyen etkenler.

Açık Yazılımın Olgunluğunu Belirleyen Etkenler

1. Liderlik ve Proje Kültürü: Daha önce de community'sine bak, open source'u al şeklinde ifade ettiğim gibi, açık yazılımın kalitesini proje lideri ve çevresindeki community belirliyor. Büyük açık yazılım projelerinin liderleri açık yazılım dünyasına katkıları sebebiyle haklı bir şöhrete sahipler (Gavin King->JBoss, Scott Ferguson->Resin). Proje liderinin tutumu da projenin kültürünü etkiliyor. Örneğin her eleştiriden kıl kapan bir liderse proje gelişemiyor. Bu yüzden, projenin olgunluğunu anlamaya çalışırken projenin liderine ve oluşturduğu kültüre bir göz atmak akıllıca.
2. Community'nin Şekli Şemali: Projenin kullanıcıları ve geliştiricileri arasında belirli bir ayrım oluştuysa, bu projenin olgunluğuna bir işaret olabiliyor. Forumlarda verilen cevaplara bakarak projenin community'si hakkında genel bir fikir edinmek mümkün. Ayrıca community'nin aktif üyelerinin çokluğu, download sayısının yüksekliği de iyiye işaret.
3. Destek Kalitesi: Yine forumlardaki aktiviteye, sorulan sorular ve verilen cevapların derinliğine ve -mevcutsa- Sıkça Sorulan Sorular bölümüne bakılarak destek kalitesini anlamak mümkün. Herhangi bir sorun yaşamanız durumunda ne kadar sürede ve ne kadar doyurucu bir cevap alabileceğinizi kestirebilirsiniz.
4. Kurulum Paketi Kalitesi: Açık yazılım projelerinin genellikle kurulum paketi falan olmuyor. Hatta büyük kısmını download ettikten sonra compile etmeniz gerekiyor. Eğer farklı işletim sistemleri için kurulum paketi varsa, pek şüpheniz olmasın, proje gayet olgundur, afiyetle yenilebilir.
5. Kod ve Dizayn Kalitesi: Ortalama bir yazılımcı, kodu ve dosyalandırma yapısını biraz incelediğinde kalitesini az çok anlar. Projenin kaynak kodunu inceleyerek geliştiricilerin projeyi ne kadar ciddiye aldığını anlayabilirsiniz. Olgun açık yazılım projelerinde bu konuya çok önem veriliyor, hatta bazı projelerde liderin elinden geçmeden tek satır kod commit edilmiyor. Koda bakınız, olgunluğu anlayınız.
6. Mimari Kalitesi: Bir önceki maddeye benzer bir madde. Kod mimarisini incelerseniz özenli mi özensiz mi olduğunu anlayabilirsiniz.
7. Test: Kodun içerisinde bol bol unit ve integration test bulunuyorsa iyiye işaret.
8. Diğer Projelerle Uyum: Projenin, depend ettiği diğer projelerin eski ve yeni versiyonlarıyla uyumu da olgunluğuna işaret ediyor. Farklı versiyonda bir dependency kullandığınızda çakılıyorsa, proje henüz gençtir, hayattan öğrenecekleri vardır. Bırakın öğrensin. Olgunlaştığında yersiniz.
9. Proje Web-Sitesinin Kalitesi: Kitapta bu madde sonlara konulmuş fakat bence ilk sıralara konulabilir. Projenin sitesini biraz kurcalarsanız projenin hangi aşamada olduğunu, ne kadar destek alabileceğinizi vs. kısa zamanda anlayabilirsiniz. Bu noktada yazar kendini tekrar etmeye başlamış.
10. Lisans Türü: Bu maddenin projenin olgunluğuyla pek alakası yok aslında. Yani projeyi kendi ürününüzle dağıtacaksanız tabii ki lisansının buna izin verip vermediğini bilmeniz gerekiyor. Ne alakası var bunun olgunlukla?
11. Baba Desteği: Projenin arkasında para babası şirketlerin desteği varsa (IBM ve Apache örneği) gönlünüz rahat olsun.

Bu bölümün sonunda, yukarıdaki kıstaslar kullanılarak projenin olgunluğuna not verebilmek için bir tablo konulmuş. Bu şekilde notlamaya ne kadar gerek var bilemiyorum. Projeyi kullanacak yazılımcıların bilgi ve deneyim seviyesini biliyorsanız, yukarıdaki kıstasları kullanarak yazılımın sizin için uygunluğunu değerlendirmeniz mümkün.

Başta da söylediğim gibi, bazıları olgun sever.

Open Source for the Enterprise - Ya da - Ucuz Etin Yahnisi - Bölüm 1

Ucuz etin yahnisi ne kadar iyi olabilir? Eti alan kişi etin kalitesinden anlıyorsa, yemeği pişiren kişi bu etten en lezzetli yemeği yapacak gönüle ve yeteneğe sahipse, yemeği yiyen kişi de yemek yeme adabını iyi biliyorsa ve damak tadı gelişmişse, ucuz etin yahnisi çok güzel olabilir.

Bu kitap, ucuz etten yahni yapmak isteyen IT departmanları için yazılmış. Cevaplanmasına yardımcı olduğu soru: Ucuz etten ne kadar iyi yahni yapabiliriz? Tabii ki bu sorunun cevabını vermiyor, fakat sağlıklı cevabı bulmak için sağlıklı yöntemler sunuyor. Ucuz etin getirileri kısaca şöyle:

• Sizi kendisine bağımlı hale getiren kasaplardan bağımsızlık
• Maliyetlerdeki muhteşem düşüş
• Ucuz mal pazarındaki binlerce bağımsız kasap, manav, mefruşatçı ve diğerlerine erişim (SourceForge, FreshMeat)

Açık yazılım kullanabilmek için gerekenler ise şu şekilde:

• Seçilecek etin kalitesinin, şöyle ete bakıldı mı hemen anlaşılması
• Hem seçim, hem pişirme, hem de saklama süreçlerindeki ustalığın çalışanlarda geliştirilmesi
• Yapılan yemek satılacaksa, kullanılan malzemenin lisansının gerektirdiklerinin anlaşılması (bu madde atılabilir, pek kimse takmıyor genellikle)

Açık Yazılım Tartışması

Yazılımcının ustası açık yazılımı sever çünkü: açık yazılım özgürleştirir, ucuzdur ve daha çok kontrol imkanı verir, sizi kontrol etmez, siz onu kontrol edersiniz.

Yönetici kısmısı ise genellikle açık yazılım istemez çünkü: bu malı bana satan yok, biraz tuhaf; hem bu yazılımcılar 3 gün derler, 5 günde yaparlar, bir sürü para... Bir de açık yazılımın desteği yok dökümanı yok belli bir firması yok... İşler kötü giderse ben kime bağırıp çağırayım? Yazılımcılara bağırıp çağırılmaz bırakıp giderler Allah korusun.

Akla en uygun yol ise, yahniyi yapmadan önce, kurumun ucuz etten ne kadar iyi yahni yapabileceğinin iyice düşünülmesi ve ona göre karar verilmesi. Kurum birikimsiz ve hımbıl ise en güzel ambalaj seçilecek, yetenekli ve zeki ise (Amazon, Google) açık yazılım seçilecek.

Açık Yazılıma Ne Kadar Hazırsınız?

Bu sorunun cevabı alınan etin kalitesine ve aşçıların ustalığına bağlı. Bir kısım açık yazılım, destek ve döküman eksikliği sebebiyle çok ciddi bilgi gerektirirken MySQL, Apache, PHP gibi daha olgun projeler ciddi bir bilgi birikimi gerektirmiyor. Kurumun yeterince parası varsa, takımını ucuz etten en iyi yahniyi yapacak şekilde eğitebiliyor, bunun için gereken zamana ve emeğe kıyabiliyor. İyi de yapıyor, çünkü IT takımı cin gibi oluyor ve kurumu havalara uçuruyor. Ne de olsa bir kurumu taşıyanlar önce hizmetliler, daha sonra IT'cilerdir.

Karar verilirken sorulacak sorular:

• Yapılacak yemek nedir?
• Bu yemeğin malzemesini sağlayan açık kaynaklı manavlar ve kasaplar mevcut mu?
• Mevcut kasap ve manavların malzemeleri ne kadar kaliteli? Bu kaliteyi değerlendirecek akıl sizde var mı?
• Bu akıl sizde yoksa ne kadar zamanda edinebilirsiniz? Bir bilene danışsanız olur mu?
• Bütün masraflar toplanınca "Yahu Migros'tan alsak daha ucuza gelirdi ve daha kaliteli olurdu" deniliyor mu?

Kısaca, açık yazılım kullanmak bilgi-işlem birimine ciddi bir sorumluluk getiriyor. Bulunması ise ticari yazılım kadar kolay değil çünkü reklam yapılmıyor, arayıp bulacaksınız. Bu da gayet normal çünkü bu yazılımı üreten adamların "pazarlama bütçesi" gibi kavramlarla pek işi olmuyor.

Açık yazılımın dökümantasyonu da sağlıklı olmuyor çünkü hiçbir yazılımcı döküman yazmayı sevmez. Açık yazılım, yazılımcılar için yazılımcılar tarafından geliştirilir. MySQL ve Apache gibi büyük projeler hariç bilgi düzeyi düşük sıradan kullanıcı genellikle umursanmaz.

Fakat; açık yazılım beleştir, ve kaliteli olma ihtimali vardır. Bugünlerde bazı açık yazılım kuruluşları 24/7 kurumsal destek için ücret alıyorlar fakat ticari yazılımla kıyaslandığında halen çok ucuz kalıyor.

Açık Yazılım Nasıl Oluşur, Nasıl Yaşar, Nasıl Ölür, Cennete mi Gider Cehenneme mi?

Programcının biri kendi sorununa çözüm üretmek için bir program yazar. Bu ilk çözümü aynı sorunu yaşayan diğer yazılımcılarla paylaşır. Proje ilgi görürse daha çok katılımcı ve kullanıcı bulur. Projenin lideri ve yönetim biçimi ortaya çıkar ve proje sürekli hale gelirse olgunlaşmaya başlar. Başarı devam ederse büyük şirketlerden ve hatta devletlerden de maddi manevi destek alır ve yazılımcılar dışında da kullanıcı bulmaya başlar(OpenOffice).

Proje bu aşamaların herhangi birisinde ölse bile kodları internette bulunabilir, dileyen kişi alıp geliştirmeye devam edebilir. Yani açık yazılım projesinin ölmesi yoktur, durması vardır. MySQL örneğinde olduğu gibi ateş tarafından yutulursa ne olur, onu da ilerleyen zamanda göreceğiz.

Projenin değerlendirilmesi için çevresindeki topluluğa bakmak önemlidir. Yani, community'sine bak, open source'u al durumu vardır.

Ürünleştirme: Açık Yazılımda Sanki Birşeyler Eksik Ama Ne?

Yazılımcıların yüzde 99'u ürünleştirmeden, pazarlamadan anlamaz. Açık yazılım bu yüzden solgun ve renksiz gözükür. Rengi verecek olan kullanıcıdır. Açık yazılım kullanacak kurumun bunu göze alması gerekir.

Ticari Yazılım ve Açık Yazılımın Risk Karşılaştırması

Sıkıldım. Bu kitap aynı şeyleri tekrar edip duruyor. Bu bölümü de sizin hayalgücünüze bırakıyorum. Buraya kadar sabredip okuduysanız gerisini tahmin edersiniz. Sevgiler.

Açık Kaynak Kodlu Kurumsal Çözümler

Bir süredir açık kaynak kodlu yazılımın kurumsal çözümlerde ne kadar kullanım alanı bulabildiğini, kurumların açık kaynak kodlu yazılıma geçişte yaşayabileceği sorunları ve bu geçiş sonucu alacakları riski ve elde edecekleri faydaları merak ediyordum. Biraz araştırma yaptıktan sonra bu konu üzerine Dan Woods ve Dani Guliani tarafından yazılmış bir kitap buldum: Open Source for the Enterprise.

Kitapta seçim ve uygulama süreci başından sonuna kadar bütün aşamalarıyla incelemeye alınmış. Açık kaynak kodlu yazılımın bir kurum için ne gibi riskler taşıyabileceği, kurumun bu risklere karşı yazılımın seçimi ve uygulanması aşamalarında ne gibi önlemler alabileceği ve açık kaynak kodlu yazılımın firmalara sunduğu geniş olanaklar detaylı olarak incelenmiş. İnceleme birçok noktada yaşanmış örneklerle zenginleştirilmiş.

Kitap toplam on bölümden oluşuyor. Yarından itibaren her gün bir bölüm olmak üzere kitabın özetini burada yazacağım.

IBM'in Eclipse IDE'yi açık kaynak kodlu hale getirmeden önce projeye 40 milyon dolar yatırdığını biliyor muydunuz?

Yapılacaklar Listesi

Planlar ölü doğar. Kendi tecrübeme dayanarak söyleyebilirim ki işe yarayan plan değil, planlamadır. Bu planlamanın ürünü sabit bir plan değil, her an değişebilen bir haritadır. Kağıt üzerinde bu esnek ortamı sağlamak benim için mümkün olmuyor. Bir ara Google Calendar kullandım; tasarımı gayet güzel ve kullanışlı fakat internete bağlanmak zorunda olmam Google'ın çözümünden vazgeçmeme sebep oldu.

Bu iş için kullanılabilecek ücretsiz bir yazılım buldum: Swift To-Do List. Programı şu adresteki "Download Now" linkinden indirebilirsiniz:

http://www.dextronet.com/swift-to-do-list.php

Şimdilik Türkçe desteği yok fakat yakında olabilir. Görsellik açısından biraz zayıf olsa da çok hafif ve kullanışlı bir program.

Bir Yaklaşım Sıkıntısı

Ekşi Sözlük'te "Embedded System" başlığı altında 14 sıra no'lu yorumu yazan arkadaş bakın neler diyor:

optimizasyonu, hedeflenen kaynak ne olursa olsun en yüksek seviyede tutmayı düstur edinmiş ve yine akademik ortamda bunun matematiksel ve pratik olarak nasıl uygulanacağını pekiştirmiş ortalama bir programcı kolayca adapte olabilir. zaten dünyanın tamamında şirketler ezici oranla embedded ve vlsi türü low-level tasarım, mimari, vs. işleri için mühendis istihdam ederler.

gel gör ki .net gibi saçmalıklara gücü yeten kaymak peşinde koşan programcıların uzak durması gereken bir pratiktir bu.

Bu yazara göre "ortalama bir programcı"nın, optimizasyonun matematiksel ve pratik olarak nasıl uygulanacağını akademik bir ortamda pekiştirmiş olması mümkünmüş. Güzide akademik ortamlar... Optimizasyonu matematiksel ve pratik olarak uygulamak... ".NET gibi saçmalıklar" da (korkarım Java da nasibini alıyor) sadece "alt seviye programcı"ların uğraştığı bir oyuncak oluyor bu durumda.

Bu acaib kafaya göre, örneğin, karmaşık bir web uygulamasını assembly'de yazmak bir kahramanlık destanı olabilirdi.

Yine de, derinliklerden bihaber yaşayan yazılımcıya nispeten bu terli arkadaşa kendimi daha yakın hissediyorum.

Java Interface ile Taklalar

Bir interface'in içinde başka bir interface, hatta public class tanımlamak mümkün imiş. İlk dosyamız OuterInterface.java:

public interface OuterInterface {

    public abstract void doOuterInterfaceThing();
 
    public interface InnerInterface{
        public abstract void doInnerInterfaceThing();
    }
 
    public class ClassInTheInterface{
        private static String slogan;
        ClassInTheInterface(){
            slogan = "Worst decision is better than no decision.";
        }
        public void speakOut(){
            System.out.println(slogan);
        }
    }
}

Şimdi de hem dıştaki, hem de içteki interface'leri implement eden bir class yazalım. Bu class, haliyle her iki interface'in abstract method'larını implement edecek. Ek olarak da OuterInterface'in içinde tanımlanan public class'ı kullansın. İkinci dosya TestClass.java:

public class TestClass implements OuterInterface, OuterInterface.InnerInterface{
 
    public void doInnerInterfaceThing() {
        System.out.println("I am doing the inner interface thing.");
    }
 
    public void doOuterInterfaceThing() {
        System.out.println("I am doing the outer interface thing.");
    }
 
    public static void main(String[] args){
        TestClass obj1 = new TestClass();
        obj1.doInnerInterfaceThing();
        obj1.doOuterInterfaceThing();
  
        OuterInterface.ClassInTheInterface obj2 =  new OuterInterface.ClassInTheInterface();
        obj2.speakOut();
    }
}

Output:

I am doing the inner interface thing.
I am doing the outer interface thing.
Worst decision is better than no decision.

Böylece başımız göğe ermiş bulunuyor. Hayırlı uğurlu olsun.