Zırvalama Tahtası

Daha önceki girdimde bahsettiğim projenin adı “Sinelist” ve kendisi www.sinelist.com adresinde ikamet etmekte.

Projenin amacı izlediğimiz ve izlemek istediğimiz filmlerin listesini yaparak bunları arkadaşlarınız ile paylaşabilmenizi sağlamak, bununla beraber izlediğiniz filmlerden arkadaşlarınıza tavsiye edebilmenizi yardımcı olmak. İnsanlar eleştirmenlerden daha çok arkadaşlarının tavsiyesine uyuyorlar ve onların görüşlerine daha çok saygı duyuyorlar.

Elbette proje sadece bundan ibaret değil, kategorizasyonu kenara koyarak, etiketleme sistemini kullanmaya çalışması, kısa filmler, bağımsız yapımlar vb. ayrımlara girmeden filmleri sadece film olarak görülebilmesini sağlamak. Böylece insanların kafalarında bir ön yargı oluşturmamaya çalışmak için düşündüğümüz bir yol.

Henüz proje sadece alpha seviyesinde olduğundan pek çok konuda eksiklikleri mevcut, bu eksiklikler zamanla üzerinde çalışarak giderilmeye çalışılacak.

Bir süredir kendi projelerimden biri ile haşır neşir olup güzel güzel vakit geçiriyordum. Şu sıralar gerek kullanıcı testleri gerekse kişilerden tavsiye alabilmek amacı ile projeyi alpha seviyesinde iken açmak istedim. Tabii bu durumda bir sunucu kiralamam gerekiyordu ve en uygun fiyat/hizmet için yurt dışındaki bilinen şirketlerden birinden birkaç gün önce bir sunucu kiralamak için sipariş verdim. Tez zamanda bana kredi kartınızın ön yüzünü ve kimliğinizi scan edip gönderin diyen bir e-posta aldım ve bu mesaj ile birlikte 3 bölümlük bir macera içerisinde buldum kendimi. Öncelikle fiziksel kopyası olan bir kredi kartı kullanmıyorum bunun yerine müşterisi olduğum bankanın sanal kredi kartı hizmetinden faydalanıyorum. Bu yüzden kredi kartımın ön yüzünü scan edemeceğimi söylediğimde çalıntı kredi kartları yüzünden bu önlemi aldıklarını ve fiziksel kopyası olmayan kredi kartım yoksa yardımcı olamayacaklarını söylediler, bölüm bir böylece hüsran ile sonuçlandı. Bende başka bir firmadan tekrar sipariş verdim, ancak aynı durum ile karşılaştım ancak bu sefer artı isteklerde vardı yine kredi kartımın ön yüzü ve biri pdf biri web sayfası olmak üzere iki belgenin basılarak ıslak imza ile imzalamam ve tekrar scan edip e-posta ile göndermem gerekiyordu. Bu kredi kartı hırsızlarına yedi düvel küfür ettikten sonra satış temsilcisi ile konuşmaya başladım, eğer kredi kartım yoksa pasaportumu scan etmemi söylediler ne şanstır ki pasaportum’da yok o halde kimlik olur yeterki üzerinde imzanız ve resminiz olsun dediler, şansa bakın ki türkiyede bu tür belgeler üzerinde kendi imzanız yok bunun yerine belgeyi veren kurumun yetkilisine ait imza var. Tüm bunları anlattıktan sonra artık her nasılsa kabul ettiler ve ikinci bölüm bir umut ile sonuçlandı. Artık çözmem gereken problem bir yazıcı ve tarayıcı bulmak ilgili belgeleri basmak ve tekrar taramak gerekiyordu, bu konuda muhasebecilik yapan bir arkadaşım yardımcı oldu ve onun ofisindeki tarayıcı ve yazıcıyı kullanarak istediklerini hazırlayıp gönderdim, sunucu’nun hazır olduğuna dair bir e-posta aldım böylece üçüncü bölüm yaşasın, heyoo heyoo sesleri ile sona erdi bir nevi mutlu son

Tabii bu arada dikkatimi çeken başka şeyler de oldu, örneğin sunucu kiralayan firmalardan biri paypal ile ödeme alıyordu bu durumda önce bir paypal hesabı açıp ardından kredi kartındaki paradan oraya biraz para aktarıp ardından da sunucuyu kiralayan firmaya ödeme bilgisi için paypal hesabımı verebilirdim. anca o zaman hangi belgeleri isterlerdi merak ediyorum. Birde bana kabul ettirdikleri kullanım koşulları belgesinde eğer spam yaparsam fena ceza keseceklerini söylüyorlardı

Yakında buradan projenin gerçekleştirilmesi sırasında yaşadığım ve çözmem gereken teknik problemleri ve çözümlerini aktarmaya çalışacağım.

Şu ana kadar projenin tamamı üzerinde tek başıma çalışmamdan ve aslında teknik bir kişi olduğumdan proje üzerindeki pek çok konuda eksiklik hissedilir durumda, bu yüzden sizlerden gelecek her türlü destek ve görüşlere önem vereceğimden emin olabilirsiniz.

Neden bilmiyorum belki depreşik olduğumdan, belki değişik bir şeyler yapmak istediğimden bir ilan vermek istiyorum; “28 yıllık temiz kullanılmış, el değmemiş, hemen hemen her türlü işe yarayabilecek potansiyele sahip 1 senelik sözleşme ile kiralık kişi” diye, acaba yayınlayabilecek bir yer bulabilirmiyim? evet depreşik zamanlarımdayım yine.

Tam bir yıl iki gün önce, doğum günümde yazıştım internet sansürü ile ilgili düşüncelerimi, şimdi gerçekleşmesini bekliyorum.

doğmak,
   son’a doğru adım atmaya başlamak,
büyümek,
   yürümeyi bırakıp koşmayı öğrenmek,
olgunlaşmak,
   koşmaktan yorulduğunun farkına varmak,
yaşlanmak,
   ardına bakmak,
ölmek,
   durmak

Geliştirme süreçlerinde özellikle yazılımın kodunun paylaşılması ve gözden geçirilmesi yazılımın kararlılığı açısından önemlidir, söz dizimi kurallarından, problemlerin çözümleri için izlenen yollara kadar, yazılımın gözden geçirilmesi gelişim sürecinin ve büyümenin bir parçasıdır. Özgür yazılımlar kamu’nun desteği ile bu problemleri geniş bir zamana yayarak geliştirme süreci ile aynı anda yapmaktadır, ancak eğer uygulamanız kamuya açık değil ise bu süreç için kaynak ve zaman ayırmalısınız. Bu ayrılan zaman gözünüzde zaman kaybı olarak görülebilir ancak hata tespiti ve düzeltmesi süreçlerini hızlandırdığı bir gerçektir, dolayısı ile zaman kaybı değil bir kazançdır.

Uygulamaların geliştiriciden çıkıp son kullanıcıya ulaşma süreci bir dizi işlemi de yanında getirir bunlar; test, bugfix, ve kurulum işlemleridir. Buradaki en zor işlem ise kaynak kodun “derlenerek” test veya ürün sistemine girmesidir. Genel olarak bu işlem 3 adım içermektedir, depodan testi yapılacak uygulamanın kaynak kodunun alınması, paketlenmesi, test sistemine kurulması.
En çok hata ise kurulum sırasında yaşanmaktadır. Tüm bu süreçleri otomatikleştirmek ve tek bir noktadan yönlendirmek, kaynak kodun ürün sistemine girerken kurulum aşamasında yaşanan problemlerin önüne geçecektir.

Geliştirilme yapılan deponun depo yöneticisi veya sürüm yöneticisi tarafından dondurulması sonrasında kaynak kod içerisinde yer alan derlenmesi gereken uygulamalar derlenmeli, oluşan kütüphane ve dosyalar paketlenmeli ardından test sistemine gönderilerek paketin kurulması işlemleri tek bir buton’a tıklama ile veya bir komut çalıştırılarak yapılabilmelidir.

Bu sistemin oluşturulması ve tasarlanması tamamen uygulamaya bağımlıdır, sadece web sayfası için, örneğin geliştiricilerin yazdıkları javascript dosyaları birleştirildikten sonra minifiy edilmesi, css dosyalarının minify edilmesi işlemleri gibi. Günümüz koşullarında bir web uygulaması basit bir web sayfası olmaktan çıkmış yüzlerce ve hatta binlerce bilgisayar tarafından işlenen verilerin biz kullanıcılara anlaşılır bir dil ile gösterilmesi haline dönüşmüştür. Bu noktada sadece web arayüzü için bir script dili değil, arka planda çalışan pek çok farklı dil ile hazırlanmış uygulama söz konusudur. Bu uygulamalarında derlenerek sırası ile paketlenmesi, test sistemine kurulması ve ardından ürün sistemine aktırılması gerekmektedir. Uygulamanın paketlenmesinden kastım, örneğin sisteminizde linux kullanıyor, dağıtım olarak ise debian seçmişseniz tüm kaynak kodun derlendikten sonra deb paketi haline getirilmesidir. Böylece kurulum öncesinde veya sonrasında yapılması gereken işlemler paket yönetim sistemi tarafından yapılacaktır. (örneğin kurulum sonrası cache sisteminin temizlenmesi)

Test ortamı üzerine kurulan yeni uygulama sadece hata düzeltmeleri içerebildiği gibi yeni özelliklerde içerebilir. Test takımı bu değişikliklerin neler olduğunu hata yönetim sistemi üzerinden bilgilendirildikten sonra test etmeli, bulunan hatalar hata takip sistemi üzerinden geliştiricilere bildirilmelidir. tespit edilen hatalar geliştirici takım tarafından düzeltildikten sonra tekrar test takımına teslim edilmeli ve her hangi bir hataya rastlanmamış ise ürün sistemine geçiş süreci başlatılmalıdır.

Uygulama geliştiricileri her ne kadar unit test yazmaktan pek fazla hoşlanmasa da, bu unit testler sayesinde uygulamanın test ortamından ürün ortamanına geçişini hızlandırabilirler, ve eğer bir geliştirici iseniz emin olun unit testler sayesinde proje lideriniz yazılım hataları konusunda başınızı ağrıtamayacaktır

İnsanın en mutlu olduğu zaman, diğer insanlar ile bir şeyleri paylaştığını hissedebildiği zamanlardır, bu anlar çok uzakta değil benim için artık; Özgür Yazılım ve Açık Kaynak Günleri 2009 ve Linux kullanıcıları derneğinin, Linux ve Özgür Yazılım Şenliği etkinliği tek bir tarih ve tek bir mekanda, 17-18 Nisan 2009 tarihinde İstanbul Bilgi Üniversitesi Dolapdere kampüsünde gerçekleştirilecek. LKD’nin ve Bilgi Üniversitesinin tek bir çatı altında beraberce bir etkinliğe imza atmaları oldukça ilginç bir etkinlik gerçekleşeceğine işaret sanırım. Şimdiden yüzümde bir gülümseme ile dolaştığım düşünülürse bu etkinlik boyunca oldukça mutlu biri olacağıma eminim ve elbette orada olacağım.

(Yazar) Sevgili günlük
(Günlük) Yine unuttuğunu sandım,
(Yazar) Beni bir heyecan sardı günlük
(Günlük) Bazen seni anlama zorluğu çekiyorum.

Dökümantasyon ve kaynak kod yönetimi gibi problemler ekip içerisinde çeşitli araçlar ve yöntemler ile çözüldükten sonra bir başka sorun kendini göstermeye başlar, problemlerin takibi ve çözümü, kaynak kod ve proje büyüdükçe problemlerin tespiti ve giderilmesi bir kaç dakikadan saatlere, günlere ve hatta daha uzun süren bir zamana yayılmaktadır.

Geliştirici hangisini yapacağına tam olarak karar veremez ve işin hep en zevkli tarafını yani yeni özelliklerin eklenmesini tercih eder. Bu tercih ise geçmişte yaşanan problemlerin ve/veya çözümlerin unutulmasına ve daha büyük sorunların çıkmasına neden olur. Bu durumu önlemek için tavsiyem kaynak kod yönetim yazılımınız ile entegre çalışabilen bir hata takip sistemini devreye almanızdır.

mozilla tarafından geliştirilen bugzilla, edgewall grubu tarafından geliştirilen trac, tigris grubu taranfından geliştirilen mantis bu uygulamalardan sadece bir kaçıdır.

Bugzilla
mozilla tarafından geliştirilen bu yazılım perl kullanarak hazırlanmıştır, modüler yapısı sayesinde subversion ve cvs‘in commit hooklarına eklenen ufak scriptler sayesinde her iki kaynak kod yönetim sistemi ile entegre çalışabilir.

Trac
edgewall tarafından özgür olarak geliştirilen ve modüler yapısı ile subversion‘ı hedef alarak geliştirilmiş bir hata takip sistemidir, küçük ve orta ölçekli subversion kullanılan her proje içerisinde kullanılabilinir. Subversion ile entegrasyonu sayesinde commit mesajları ile her hangi bir hata kaydı kapatılabilinir. içerisinde dahili olarak subversion için web arabirimi, hata takip sistemi ve wiki hazır olarak gelmektedir böylece tüm projedeki gelişmeler tek bir adres ve arabirimden geliştiricilere, katkıcılara, testçilere ve hatta kullanıcılara ulaştırılabilinir.

Mantis
Php ile yazılmış bu hata takip sistemi sadece hata takibini sağlamak için geliştirilmiştir, subversion veya cvs için commit hook’larına eklenen ufak betikler sayesinde kaynak kod yönetim sistemleri ile entegrasyonu sağlanabilir.

Redmine
Pek çok farklı kaynak kod yönetim sistemi ile entegre çalışabilen ve ruby ile geliştirilmekte olan bir takip aracıdır, çoklu dil desteği, forum, wiki, hata izleme sistemi, takvim ve birden fazla proje için kullanılabilmesi ile dikkat çekmekte olan başarılı bir araçtır. Tıpkı trac gibi geliştiricilerin, katkıcıların tek bir adres üzerinden rss ile takibini mümkün kılmaktadır.

Zaman içerisinde sağlıklı ve kararlı bir büyüme gerçekleştirmek istiyor iseniz işe en başından projenizin yazılımsal kontrolünü elden bırakmadan yapmak zorundasınız. Uygulamanızın daha fazla kişi için erişilebilinir olması, uygulamanız, iş modeliniz, sermayeniz ve kullanılacak teknikler ile değişiklik gösterebilir, ancak kaynak kod yönetimi ve hata takip sistemi gibi “genel yapılar” geliştirme sürecinde değiştirilemez parçalarıdır. Bu neden ile bu başlıklar “ölçeklenebilir yazılım geliştirme” altında bulunmaktadır. Yukardaki uygulamalar irili ufaklı hemen hemen her projede kullanılması gereken, iş gücünün dağıtımını ve yönetimini başarı ile yapabilmenizi sağlayan araçlardır. Bir projenin büyümeyi planlayabilmesi için öncelikli olarak geliştiricilerine yukardaki araçları tanıyabilmesi ve kullanabilmesi için gerekli eğitim ve zamanı tanıması gerekmektedir.

Tek tabanca çalışan yazılımcılarda gözlemlediğim diğer bir dezavantaj ise kaynak kod yönetimi için her hangi bir araç ihtiyacı hissetmemesidir. Bu nedenle özelliklede takım çalışması sırasında en çok ihtiyaç duyacağınız kaynak kod yönetim araçlarının eğitimi ve kullanım alışkanlığının oluşturulması zaman alacaktır. Ticari olarak geliştirilen Kaynak kod yönetim araçları özellikle bir startup için oldukça maliyetli olabilir, bu neden ile özgür yazılım olarak kullanılan araçlar içerisinden en çok kullanılanlarına bir göz atalım, CVS, GIT ve Subversion, her aracın kendine özgü avantajları ve dez avantajları mevcuttur bu araçlardan hangisinin kullanılacağı ise genel olarak proje içerisinde yer alan yazılımcıların genel olarak hangi aracı daha rahat kullanabileceği ile ilgilidir, zamanla mevcut kullanılan kaynak kod yönetim aracının değiştirilmesi söz konusu olabilir.

GIT
Git, linus torwalds tarafından linux kernel kaynak kodunun idaresi için geliştirilmeye başlanmış ve ardından pek çok geliştiricinin desteği ile gelişimine devam etmiştir, linux kernel’i gibi oldukça büyük ve binlerce kişi tarafından geliştirilen bir uygulama için kullanılan bu araç pek çok kişinin ve şirketin dikkatini çekmiş ve son bir yılda oldukça popülerleşmeye başlamıştır. GIT diğer kaynak kod yönetim uygulamarından bazı özellikleri ile ayrılmaktadır, başlıca özellikleri dağıtık bir mimari sunmaktadır, bir depo’yu kullanmak istediğinizde deponun tüm tarihi bilgisinide alırsınız. Bir depo ihtiyacı duymaz ve yerel olarak çalışabilir, bu sebeble bir git sunucusuna ihtiyacınız yoktur.

CVS
1986 dan beri geliştirilen ve oldukça sık kullanılan bir araçtır, eski olması nedeni ile pek çok windows, unix ve mac üzerinde istemcileri mevcutur. modüler yapısı sayesinde pek çok araç ile entegre çalışabilir. pluginleri sayesinde RSS üretebilir, commit logları farklı veri tabanı üzerinde tutulabilinir. Ayrıca web üzerinden de kaynak kodlar üzerindeki değişiklik takip edilebilinir, rss ve mailing ile son değişiklikleri geliştiricilere iletebilirsiniz.

Subversion
2000 yıllında geliştirilmeye başlayan bu araç CVS de bulunan pek çok zenginliği taşımaktadır. moduler yapısı sayesinde CVS için kullanabileceğiniz yardımcı araçları subversion içinde bulabilirsiniz. subversiyonun geliştirilme amaçlarından biri olan CVS’de bulunan bir takım önemli problemleri kapatmak ve geliştiriciler için daha kolay bir kullanım sunmaktır. Subversiyonda’da commit loglarını ayrı veri tabanında tutabilir, web arabirimi ile kaynak kodlar üzerindeki değişiklikleri takip edebilirsiniz, rss ve mailing ile son değişiklikleri geliştiricilere iletebilirsiniz.

Unutmamanız gereken şey yukardaki her araç sadece ve sadece kaynak kod yönetimi için geliştirilmiştir, rss, mailing ve web arabirimleri için bu araçlar ile entegre çalışan farklı uygulamaların mevcut olduğu ve içerisinde hazır çözüm olarak gelmediğidir.

Kişisel tercihim olarak kullanım ve yönetim kolaylığı nedeni ile subversiyon’dur ancak projenin ihtiyaçları doğrultusunda bu seçim değişebilir.

Kaynak kod yönetim sistemlerinin kullanılmaması pek çok girişim ve projenin geliştirme süreçleri büyüme arttıkça doğru orantılı olarak uzamakta veya gelişimini devam ettirememesine neden olmaktadır. Geliştiricilerin bu tür araçları kullanmaya alıştırmak için ise benim kişisel yöntemlerimden biri commit mesajlarına ufak tefek proje ile ilgisiz genelde şakacı yada gönderme yapan mesajlar geçmektir. bir süre sonra commit mesajları geliştiriciler arasında online iletişim aracı haline gelecektir

$ svn commit dosya.txt -m "fixed #5454
>
> 
> detan böcekkıran böceklerle olan savaşında bir kez daha kahramanca galip gelir."

$ svn commit dosya.txt -m "
> typo hatası, indentlere dikkat etmek lazım gelir.
> 
>  çeşme başında gezmeli,
>  güzeli uzaktan süzmeli,
>  eğer gönlü var ise,
>  istemeye gitmeli."

Türkiye’de özellikle yazılım üzerine eğitim almış kişiler, eğitim yöntemleri nedeni ile hep bireysel çalışmaya odaklılardır. Bunun sonucu olarak tek tabanca tüm yazılımı tamamlamak normal bir şey gibidir. Bu yüzden yazılımın dökümantasyonuyla ilgili pek fazla çalışma yapılmaz, bu nasıl yapılır, ne tür araçlar kullanılır bilinmez. Eğer bir startup için bir yazılımcı ile anlaşacaksanız sormanız gereken şeylerden biri kullanılacak olan dili’de dikkate alarak örn: PHPDoc, JavaDoc gibi yazılımın kaynak kodu üzerinden dökümantasyon çıkartmak için kullanılan söz dizimi hakkında bilgi sahibi olup olmadığı, daha önce bu tür bir şey yapıp yapmadığı olmalıdır. Bu söz dizimleri öğrenmesi oldukça kolay ve sadece 5 dk. alacak şeylerdir dolayısı ile bilip bilmemesi pek fazla sorun değil ancak bu sorumluluğunun farkında olması açısından önemli bir göstergedir.

Bir proje yaşadığı sürece pek çok farklı yazılımcı dahil olacak veya ayrılacaktır, ayrıldığında projenin devam edebilmesi ve yeni gelen yazılımcıların hızlıca projeye dahil olması açısından önemli bir ayrıntıdır aksi halde her yeni katılan yazılımcı tekerleği yeniden hazırlayacaktır. Aşağıda görebileceğiniz gibi kaynak kod üzerinden dökümantasyon oluşturmak aslında oldukça kolay bir işlemdir. Her ne kadar örnek PHP ve PHPDoc üzerinden verilmiş olsada hemen hemen her dil için benzeri araçları bulmak yada uygulamak mümkün.

Söz dizimi:
/**
  * String sınıfı string işlemleri ile ilgili
  * doğrulama ve ayıklama işlevlerini yerine
  * getirmek amacı ile hazırlanmıştır.
  * @package projectname
  * @subpackage dogrulama
  */
 class String
 {
 
  /**
   * parametre olarak verilen string içerisinde eğer var ise
   * 0-31 ascii kodu arasındaki kontrol karakterlerini siler
   * ve temizlenmiş string verisini geri döndürür.
   * {@source 3 1}
   * @param string $string kullanıcıdan gelen string veri
   * @return string kontrol karakterlerinden arındırılmış string veri
   * @access public
   */
   static public function clearControlChars($string)
   {
     return preg_replace('#\p{C}#u', '', $string);
   }
}

Projenin kod tabanındaki dökümantasyon proje büyüdükçe önem kazanmaktadır, yeni katılan geliştiricilerin başları sıkıştıkça bakabilecekleri bir kaynak bulunması geliştiricileri oldukça rahat hissettirecektir. Dökümante edilmemiş bir kod yığını içerisinde yeni bir geliştirici her hangi bir sorunun kaynağını ararken veya yeni bir geliştirmeyi eklerken kullanabileceği araçları tam olarak bilemeyeceğinden dolayı bunun için en kısa yol olan “bir bilene soralım” yolunu izleyecektir, bu durum daha tecrübeli olan geliştiriciyi çalışırken bölmek ve dikkatini dağıtmak anlamına gelmektedir, dikkati dağılan geliştirici tekrar konsantre olmak için bir süre oyalanacak ve ilerleyen zamanlarda bu durumun devam etmesi geliştirici üzerinde huzursuzluğa neden olacaktır. Diğer bir durum, yeni katılan geliştirici soru sormak yerine çözümü kaynak kod içerisinde aramayı denemesidir, ancak bu da çok fazla zaman alacaktır ki bir süre sonra ne aradığını hatta neden aradığını bile unutabilir. (kendimden biliyorum :)) yukarıda bahsedilenler, dışarıdan bakıldığında gelişticinin suyu çıkıncaya kadar çalıştırılacağı veya çalıştırıldığı izlenimini verebilir ancak anlatılmak istenen, dikkat dağıtıcı unsurları azaltmak veya problemlerin cevaplarını kolayca bulmanın yolları var iken bunların görmezden gelinmemesidir. İyisimi siz dökümantasyona önem verin.

(Yazar) Sevgili günlük…
(Günlük) Sizin yolunuz pek sık düşer oldu, hayırdır?
(Yazar) Geçmi kalıyorum?
(Günlük) Geç kalmıyorsun, gitmesini, geçmesini bekliyorsun, bekleme…