Zırvalama Tahtası symfony, debian, PHP5, SQL ve pek çok ayrıntı

30May/101

Düşünüyorum

V8'in gayet güzel bir arabirimi var, nodejs projesinden de görülebileneceği gibi geliştirme yapmakda oldukça kolay, javascript oldukça yaygın bir dil ve geniş bir kullanıcı ağı var.

Peki, acaba linux kerneli ve V8 javascript engine kullanan bir işletim sistemi olamaz mı? Linux boot sürecinde init yerine V8'i çalıştırsa ve V8 her bir terminal için javascript shell çalıştırsa? şu anda V8'in shell erişimi sadece bir kaç ufak tefek komutdan oluşuyor ancak güzel bir geliştirici katkısı ile hazır haline geçmesi pek sorun olmaz diye düşünüyorum. sistem üzerinde bulunacak tüm kütüphaneler sadece ve sadece kernel'in ve V8'in ihtiyaç duyacağı kütüphaneler olsa, bir JsOS'un prematüre hali olabilir mi?

(Yazar) - Sevgili günlük
(Günlük) - Her istediğinde hatırlayacağın birimiyim ben?
(Yazar) - ...........
(Günlük) - Aleyhinde kullanacağım

8Apr/103

Cassandra

Cassandra, facebook tarafından geliştirilmiş ve daha önce amazon tarafından geliştirilen Dynamo ile benzer yapıya sahip yapısal key/value veri tabanıdır. Cassandra veri modeli oldukça basittir, geliştirme yapmak oldukça hızlı ve eğlencelidir. Ancak eğlenmeden önce Cassandra'nın veri modellerini anlamak gerekiyor.

Cassandra veri modeli için Keyspace, ColumnFamily, Column, Key, SuperColumn tanımlarını kullanır.

Keyspace

Keyspace basitçe verinizin ait olduğu veri tabanı adıdır diyebiliriz. Keyspace'ler kurulumunuzun yapılandırmasına bağlı olarak /var/lib/cassandra/data/ dizini içerisinde bulunurlar. Eğer SQL'e aşına iseniz SQL'de bulunan veri tabanı adı ile Cassandra'da bulunan Keyspace'in aynı anlama geldiğini düşünebilirsiniz. SQL'den farklı olarak istemciden Cassandra'ya açılan bağlantının hangi veri abanına ait olduğunu söyleyemezsiniz, başka bir değiş ile "use dbname" gibi bir deyim Cassandra üzerinde bulunamamaktadır bu nedenle verilerinizi yazarken veya okurken verinizin hangi "Keyspace" üzerinde olması gerektiğini Cassandra'ya söylemelisiniz.

ColumnFamily

ColumnFamily ise, Keyspace içerisinde bulunan gruplanmış verileri taşıyan tablo olarak düşünülebilirsiniz. Bu tablolar verinize ait satırları tutmaktadır. SQL'den aşina olduğumuz sütünların row haline gelmiş halleri olarak düşünebilirsiniz ancak SQL'de tablo tanımı sırasında belirtilen sütünların ColumnFamily içerisinde tanımlanmasına gerek yoktur. Bir Keyspace içerisinde istediğiniz kadar ColumnFamily tanımlayabilirsiniz.

Key

Key'ler ColumnFamily içerisinde bulunan ve SQL'deki primaryKey alanına denk gelen, verilerinize erişmek için kullanabileceğiniz alanlardır. Key içerisinde bulunan veriler Cassandra için birer "Satır"dır. Ancak bu satırların SQL'de bulunan satırlar olmadığını hatırlamalısınız. Bir ColumnFamily içerisinde istediğiniz kadar Key barındırabilirsiniz.

Column

Column ise Key'lerin içerisinde bulunan sütunlardır. Bu sütunların yapısı SQL'de bulunan sütünlardan oldukça farklıdır. sütunlar içerisinde 3 adet alan bulunmaktadır. Bu alanlar "name", "value" ve "timestamp"'dir. Tabloların SQL'deki gibi bir yapısı olmadığını söylemiştik, işte bu nedenle Column içerisinde name ve value değerleri bulunur timestamp ise karışıklığı önlemek içindir. Tüm yapının anlaşılması için her hangi bir dilde bulunan Array veya hash dictionary'den faydalanabiliriz. Bir key içerisinde istediğiniz kadar Column tanımlayabilirsiniz.

  $Keyspace = Array(
    'ColumnFamily' => Array(
      'Key' => Array(
        'ad' =>  Array('value' => 'Timu', 'timestamp' => '1270663849'),
        'soyad' => Array('value' => 'Eren', 'timestamp' => '1270663849')
      )
    )
  );
  Keyspace = dict(
    ColumnFamily = dict(
      Key = dict(
          ad = dict('value' = 'Timu', 'timestamp' = '1270663849'),
          soyad = dict('value' = 'Eren', 'timestamp' = '1270663849')
      )
    )
  )

Column içerisinde yer alan timestamp, verinin tutarlılığını sağlamak için bulunmaktadır ve istek sırasında istemci tarafından gönderilir. Eğer Cassandra'ya aynı anda verinin güncellemesi için iki istek gönderilir ancak bu isteklerden biri network problemleri veya farklı data center'lardan gönderilmesi nedeni ile cassandra'ya geç ulaşır ise timestamp değeri mevcut verinin üzerinde bulunan timestamp değerinden küçük olacağından güncelleme işlemi yapılmayacaktır. Cassandra üzerindeki verilere "Key"'ler ile ulaşabileceğinizi söylemiştik, isterseniz bir Key içerisinde bulunan Column'lardan tümüne veya bir kısmına erişebilirsiniz.

SuperColumn?

SuperColumn'ları Key'ler içerisinde bulunan bir ColumnFamily olarak düşünebilirsiniz. ColumnFamily cassandra yapılandırma dosyasında (storage-conf.xml) tanımlanır ve SuperColumn olup olmadığı ColumnType öz niteliğinde belirtilir.
ColumnType değeri "Super" verilir ise o ColumnFamily bir SuperColumn demektir. Burada dikkat etmeniz gereken ColumnFamily'i SuperColumn olarak tanımladığınızda Key içerisinde Column türünden veri barındıramazsınız.

  $Sinelist = Array( // Keyspace
    'Users' => Array( // ColumnFamily 
      'timu' => Array( // Key
        'information' => Array( // SuperColumn, similar as ColumnFamily
          'ad' =>  Array('value' => 'Timu', 'timestamp' => '1270663849'), // Column
          'soyad' => Array('value' => 'Eren', 'timestamp' => '1270663849') // Column
        ),
        'images' => Array( // another SuperColumn
          'thumbnail' => Array('value' => 'http://static.sinelist.com/users/xxxx.jpg', 'timestamp' => '1270663849')
        ) 
      )
    )
  );

Tıpkı ColumnFamily içerisinde ki Key'e ait sütunların tamamına veya bir kısmına nasıl erişiyor isek aynı şekilde SuperColumn için de erişebiliriz. SQL'de bulunan tablolar arası ilişkiler Cassandra üzerine bulunmamaktadır, dolayısı ile veriler arası ilişkileri uygulama tarafında halletmek zorundasınız.

Sıralama

Şu ana kadar Cassandra'nın verileri nasıl organize ettiğini anlamış olduk. Ancak dikkat etmemiz gereken bir unsur daha var ki o da
sıralama. Cassandra'ya verinizi insert ettiğinizde nasıl bir sıralama ile tutması gerektiğini söyleyebilirsiniz, böylece veriyi her zaman sıralı olarak alabilirsiniz.

Cassandra üzerine bulunan Column'lar her zaman Column adına göre sıralı olarak tutulur. Bu sıralama storage-conf.xml dosyasında ColumnFamily tanımlanırken CompareWith öz niteliğine verilen değer ile belirlenir, cassandra ön tanımlı olarak BytesType, UTF8Type, LexicalUUIDType, TimeUUIDType, AsciiType, ve LongType sıralama methodlarını kullanabilir. Bu yöntemlerden her hangi birini seçtiğinizde dikkat etmeniz gereken şey Column adlarının belirtilen sıralama algoritması ile uyumlu olması gerektiğidir. Eğer CompareWith parametresi LongType ise sütun adları 64bit (8 byte) integer uzunluğunda olmak zorundadır. Sıralama her zaman büyükten küçüğe doğrudur.

Eğer ColumnFamily bir SuperColumn ise CompareWith parametresi Key isimlerini etkiler ve sıralama key'ler için yapılır. Sütünların sıralanması ise CompareSubcolumnsWith parametresi ile belirtilir.

Sayfalama

Cassandra ile çalışırken sayfalama yapmak istediğinizde ortaya bir sorun çıkar, bu sorun SQL'den alışık olduğumuz offset değerinin sayısal bir değer olmamasından kaynaklanır, Cassandra için offset değeri bir key olmalıdır, Cassandra'ya şu kadar kayıttan sonra bana 10 tane kayıt ver diyemez ancak şu kayıt ile birlikte bana 10 tane kayıt ver diyebilirsiniz. Burada dikkat etmeniz gereken cassandra size verdiği veriler içerisinden belirtmiş olduğunuz key'e ait verilerin de bulunduğu bu yüzden sayfalama yaparken eğer başlangıç değeri verilmemiş ise 10 tane verilmiş ise 11 tane kayıt çekip başlangıç bilgisi verilen kayıdın kullanıcıya döndürülecek cevap içerisinden çıkartmanız gerekebilir.

Replikasyon

Cassandra içerisinde replikasyon için 3 adet yöntem bulunmaktadır, bunlar RackUnaware, RackAware ve DatacenterShard'dır. Rackaware eğer birden fazla data center ile çalışıyor ve içerisinde kendimize ait bir network kurabilmiş isek faydalıdır aksi halde bir anlamı yoktur. Bir Cassandra makinesine gelen yazma isteği replikasyona tabii tutulacak ise replikasyon methoduna göre bir node seçilir eğer data center içerisinde her hangi bir network kurulumuna gitmemiş isek RackUnaware yöntemi bizim için kullanışlı olacaktır. Bu yöntem Cassandra kurulumlarından bir tanesini rastgele seçerek replikasyonu gerçekleştirecektir. Eğer kendi networkümüz var ve replikaslikasyon yöntemi olarak RackAware kulanırsak, cassandra replikasyon için önce farklı bir data center da bulunan bir node aramaya çalışır bulursa replikasyonu gerçekleştirir, eğer bulamaz ise bu sefer aynı data center içerisinden farklı bir rack bulmaya çalışır ve bulursa replikasyonu gerçekleştirir. Cassandra data center'ları ve Rack'leri bulabilmek için gossip (dedikodu) ile oluşturduğu node listesi içerisindeki ip adreslerine bakarak karar verir. Node listesindeki ip adresinin her birinin 2 nci byte'ı kendi ip adresinin 2 nci byte'ı ile aynı ise ve 3'ü byte'ı kendi ip adresinin 3'ncü byte'ından farklı ise aynı data center içerisinde farklı bir rack, eğer 2 nci byte'ı kendi ip adresinin 2 nci byte'ından farklı ise, node'un farklı bir data center da olduğuna karar verir. RackAware de öncelik her zaman farklı bir data center'a replikasyonun gerçekleştirilmesidir. Eğer replicationFactor 2 ve daha fazla verilirse öncelik farklı datacenter ve farklı rack'dir.

Data center 1 (ip aralığı 192.168.1.1 den 192.168.255.254)
Rack 1: (ip aralığı 192.168.1.40 den 80)
node1: 192.168.1.40
none:2 192.168.1.44
none:3 192.168.1.48

Rack 2: (ip aralığı 192.168.2.40 den 80)
node1: 192.168.2.40
none:2 192.168.2.44
none:3 192.168.2.48

Data center 2 (ip aralığı 192.167.1.1 den 192.167.255.254)
Rack 3: (ip aralığı 192.167.1.40 den 80)
node1: 192.167.1.40
none:2 192.167.1.44
none:3 192.167.1.48

Rack 4: (ip aralığı 192.167.2.40 den 80)
node1: 192.167.2.40
none:2 192.167.2.44
none:3 192.167.2.48

Tagged as: 3 Comments
23Feb/100

Tekerleği yeniden keşfetmek yada mevcut olanları sormak

Sinelist adına büyük dosyaların efektif biçimde kullanıcılara sunulabilmesi için
bir dosya sistemine ihtiyacım var ve bu dosya sisteminin ölçeklenebilir ve hata tölaranslı olması gerekiyor.

mogileFS vb. benzeri dosya sistemleri genel olarak küçük dosyalarda oldukça başarılılar ancak büyük dosyalarda talepte bulunan kullanıcı sayısı da göz ününe alındığında disk vb. fiziksel sınırlarımızıda düşünürsek aynı başarıyı
gösteremiyorlar.

Bu neden ile kullanıcı düzeyinde (kernel ile iletişime direk olarak ihtiyaç duymadan) bir dosya sistemi düşünmekteyim. Temellerini mogileFS'den alan sistem, mogileFS'den biraz farklı olarak kullanıcının erişmek istediği dosyayı disk üzerinde tek bir dosya olarak değil, 10 Mb'lik parçalar halinde pek çok farklı fiziksel disk üzerine
dağıtarak aynı dosyaya farklı zamanlarda erişmek isteyen kişiler için daha yüksek başarım sağlamayı hedefliyor.

mogileFS'in aksine dosya tek bir parçadan oluşmadığı halde dosyayı belirten işaretçin karşılığında her bir parçanın hangi fiziksel makinelerde olduğu, parça büyüklüğü mutlaka SIRALI bir şekilde dosya hakkında bilgi isteyen izleyiciye döndürülmesinin ardından, izleyici her bir parça için sıra ile ilgili node'lardan ilgili dosyayı HTTP ile istekde bulunacak ve network üzerinden edinilen dosya parçası istemciye gönderilmeye başlanacak her bir parça bittikden sonra bir diğer parça için bir başka node'a gidilerek bu süreç ilgili dosya için tüm parçaları kullanıcıya iletilene kadar devam edecek.

Yukarıda tarif etmeye çalıştığım gibi bir dosya sistemi geliştirmeyi denemeden önce hali hazırda mevcut dosya sistemleri ile büyük dosyalar (1GB ve üzeri) için haşır neşir olmuş, bilgisi ve tecrübesi olanlar yol gösterebilirse sevinirim.

1Oct/091

Dikkat edilmesi gereken projeler

Son zamanlarda ilgilenmeye başladığım uygulama/projelerden bazılarını yazayım dedim, özellikle cometd projesine göz atmanızda fayda var, malum html5 ile gelen web socket'leri ve cometd birleşince realtime web için oldukça iyi bir adım atmış olacağız.

cometd - bayeux (http://cometdproject.dojotoolkit.org/)
tornadoweb (www.tornadoweb.org)

16Mar/090

Bölüm 4) Test aşamasına geçiş

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 :)

4Mar/090

Bölüm 3) Hata takip sistemleri

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.

27Feb/091

Bölüm 2) Kaynak kod yönetim sistemleri

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."
25Feb/095

Bölüm 1) Dökümantasyon

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);
   }
}

cikti

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...

23Feb/090

yazılım geliştirme ve ölçeklenebilirlilik

Projeler ve yazılım ayrılamayan ikilidir, projeleri gerçekleştiren kişilerin kullandığı diller ve teknolojiler, projenin veya fikrin gerçekleştirilmesini sağlayan yazılımı oluştururken aynı zamanda projenin biçimlenmesinde kimi zaman olumsuz kimi zaman olumlu katkıda bulunurlar.

Türkiyede özellikle yoğun trafik yaşayan web projelerinin azlığı, yazılımcıların ilgi ve tecrübesinin olmamasını pek çok başarılı olabilecek projenin henüz daha doğmadan yok olmasına neden oluyor. Şöyle düşünün, dailymotion yada youtube daha henüz oluşturulmamış iken bir fikir sahibi olarak (teknik bir kişi olmadığınızı var sayarak) online video sitesi kurmak geldi ve çeşitli gelir modelleri belirlediniz, etrafınızdaki yazılımcılardan bu işin yapılabilinirliliği hakkında bilgi ve fiyat almak istediğinizde size bir kaç çözüm ile birlikte bir kaç fiyat çıkartılacaktır, sizde güvendiğiniz ve cebinize uygun fiyatı veren yazılımcı veya yazılımcı ekip ile yola çıktınız.

Projeniz bittiğinde ise aslında sizin elinizde olan sadece yapılacak iş için yapılabilirliliğine ait bir kanıt niteliğinde ürün oldu ancak siz henüz bunu fark etmediniz, fark etmenizi sağlayacak senaryo ise:

ilk haftada saniyede 100 request almaya başladınız, sisteminiz afalladı çünkü yazılımcılarınız ne yazıkkı ölçeklenebilirlik hakkında pek fazla bilgiye sahip değillerdi, dağıtık dosya sistemi için nfs kullanıldı çünkü daha bilinir ve daha kolay geldi, sabit içerikleri ayırmadınız, ön bellek sistemi dosya dizin seviyesinde kaldı, oturum yönetimi dosya dizin seviyesinde çalışıyor. veri tabanına yapılan sorgular önbelleklenmediği ve kimi update işlemleri için (gösterim arttırımı veya azaltımı) veri tabanına erişim yapılıyor. Tüm bu unsurların sonunda sisteminiz gelen trafiğe yanıt veremeyecek duruma gelebilir. Problemi aşmak için büyüme kaçınılmaz ancak nasıl?

Yeni çıkmış bir servisin birden bu duruma düşmesi oldukça kötü olacaktır, bu neden ile yazılım ekibinizin veya yazılımcınızın bu unsurları en başta düşünmesi ve tedbir alması gerekmektedir.

Bu unsurlara göre yazılım tasarımı nasıl olmalıdır? Kullanılabilinir araçlar, teknikler ve teknolojiler nelerdir? Büyüme problemleri, çözümleri ve maliyeti ile ilgili bir süre yazmak bir şeyler "zırvalamak" istiyorum, umarım faydalı olur.

(Yazar) Sevgili günlük...
(Günlük) beni hatırladığına sevindim, efendim?
(Yazar) Yanlış mı yapıyorum sürekli?
(Günlük) Hayatın içerisinde yapılanlar, yapıldıkları sırada yanlış değildir, bu yüzden şimdi düşünme ilerde düşünürsün.