Google App Engine’de Django 1.0 kullanmak

Google App Engine, şuan halen varsayılan olan 1 numaralı uygulama geliştirme arayüzü (API) ile yayına başladığında içerisinde o zamanın kararlı sürümü Django 0.96 ile geliyordu. O zaman bile eskimiş olan bu Django sürümü üstüne şimdi 1.0 ve onun güvenlik güncellemeleri ile örneğin şuan 1.0.2 çıkmış durumda. Google’ın App Engine için yeni bir API versiyonu çıkarmadan [...]

20 Ocak 2009

Posted In: django, Google App Engine, Linux Gezegeni

Tez çalışmam ve bulduğum hatalar

Tez çalışmamın yazımını çoğu Openoffice programını (Writer, Draw, Math) ve kmplot (ilk Google sonucu) kullanarak tamamladım (son rötuşlar olur tabi). Bu esnada Zemberek tarafından tanınamayan bazı kelimeler keşfettim ve hata kayıt sistemine raporladım. Ancak karşılaştığım hataların en ilginci Openoffice’te çıkandı. Çıktıyı (Neyse ki ciltli kopya değildi) bile aldıktan sonra arkadaşın gözle farkettiği formüllerim. Openoffice PDF çevrimi yaparken formüllerin bazılarında rakamları Arap alfabesindeki rakamlara çevirmişti. Araştırdığımda bunun bilinen ve uzun zamandır açık olan bir hata olduğunu öğrendim. Üstelik de yazılanlar gibi rasgele oluyor, bozulan rakamlar her seferinde değişiyordu. Şimdilik yazdırma için PDF’ye aktarmayı tercih edeceğim (Oysa kı yazıtipi, kayma gibi sorunlar olmasın diye özellikle PDF tercih etmiştim). Ancak PDF’ye çevirirken (CD’de PDF olarak da vermem gerekiyor sanırım) muhtemelen CUPS-PDF kullanmam gerekecek.

Ekleme: Tarık Zengin’in tavsiyesi ile dosyaya yazdır ile postscript dosyası oluşturup ghostscript ile beraber gelen ps2pdf ile pdf oluşturmaya karar verdim. Gayet de rahat oldu. Teşekkürler Tarık.


Yayınlandı gentoo, gezegen, linux, openoffice, zemberek

17 Ocak 2009

Posted In: gentoo, Gezegen, linux, openoffice, zemberek

e-bergi

İngilizce computation kavramını karşılamak üzere "tasarlanmış" bir kelime berim. Türkçe'nin bilim dili olabilmesi, yabancı dillerdeki kavramları karşılayabilmesi için pratik bir yolun "kök uydurmak" olduğu fikrinden hareketle uydurulmuş bir kök. Dil bilimciler bütün bu "uydurma" süreci hakkında ne der bilmiyorum ama ben "Yüksek Başarımlı Berim" (bkz. HPC) başlıklı toplantılar gördüğümde hiç kulağım yadırgamadı. Tamamen bir alışkanlık meselesi.

Aslında bir de tercih meselesi, bir konu hakkında konuşurken terimlerin İngilizce karşılığını kullanmaktansa, yaygınlaşmamış ve oturmamış bile olsa Türkçe karşılıklarını kullanmayı tercih ediyorum. Bu konudan rahatsız değilim, birileri sözcüğü anlamasa bile İngilizce sözcüğü kullanıp önce anlamalarını sağlıyorum, sonra konuyu Türkçe sözcükle anlatmaya devam ediyorum. Türkçe terimleri yaygınlaştırmada bu yöntemin işe yaradığını gözlemledim, "komik/garip" Türkçe karşılığı çekindiği için kullanmayanları cesaretlendiren bir davranış olduğunu düşünüyorum.

"Bermek" kökünü adında kullanan bir de sanal yayın var, e-bergi. Odak noktaları özgür yazılım ve bilgisayar bilimleri olan, ancak güncel konular, oyunlar ve biyografilerle birlikte geniş bir yelpazede yazılar içeren bir dergi. Nisan 2007'den beri yayında olduğundan ötürü geniş bir eski sayı arşivi var. Arşive bakmanızı özellikle tavsiye ederim, ilginizi çekebilecek bir konuda yazılmış bir yazı bulabilirsiniz. Siz de bir ucundan tutmak isterseniz önce dergiyi hazırlayan ekiple iletişime geçip bir konu belirledikten sonra e-bergi yazarı olabilirsiniz.

Son olarak, günlüğümdeki bazı yazılar Linux Gezegeni'nde de yayınlanıyor, [[hatta bunu okuyorsanız büyük ihtimalle bir gezegen okuyucusunuz :) ]]. Alper Kanat gezegen hakkında yazmış; demiş ki gezegendeki her şey teknik ve/veya linux ile ilgili olmak zorunda değil. Bu görüşe ben de katılıyorum, Truman Show, BBG evi ya da twitter havasında sürmediği sürece, ortak noktaları Linux ve Özgür Yazılım olan insanların günlüklerindeki diğer konuları da takip etmek ilgimi çekiyor.

17 Ocak 2009

Posted In: bergi, e-bergi, Gezegen, türkçe terim

Test Dünyasında Neler Oluyor ( Bölüm-3 Fedora)

Fedora kalite güvence ekibinin 4 ana sorumluluğu bulunuyor; Hata sınıflandırma, Güncelleme testleri , Sürüm testleri, Test araçları geliştirmek.


Hata sınıflandırma bölümünde hataların doğru insanlara atanmasını sağlıyorlar.

Güncelleme testlerini Bodhi [1] adındaki web tabanlı bir yazılım ile gerçekleştiriyorlar. Bu yapının önemli avantajlarından birisi detaylı ölçüm ve istatistikler tutmaya izin vermesi [2]. Konu ile ilgili ilginç bulduğum ilk nokta yeni paketlerin test edilip edilemeyeceği kararını paket için güncelleme isteyen geliştirici belirliyor. İkinci ilginç nokta ise paketlerin testi dondurulmuş belirli bir depo durumu içinde değil tek tek paketler üzerinde yapılıyor olması.

Sürüm testleri üzerinde oldukça detaylı çalışılan bir süreç, 2 temel kategoriye ayrılıyor güncelleme ve kurulum testleri ve yeni özelliklerin test edilmesi. Hangi özelliklerin sürüme alınacağına ve hangi hataların sürüm için engelleyici olduğuna bu testler sonucu karar veriyorlar.

Sürüm testleri için oldukça detaylı bir test planına sahipler [3] hangi ön sürümün hangi adımlara kadar sorunsuz çalışması gerektiği belirlenmiş durumda. Bundan dolayı test ettikleri adımları daha detaylı biçimde test edebiliyorlar. Özetle beklentilerini ilk adımlarda düşük tutarak eldeki iş gücünü daha verimli değerlendirebiliyorlar.

Bu kategorideki test sonuçlarını pek renkli fakat hoş bir tablo üzerinden takip ediyorlar [4] . Burada dikkatimi çeken nokta ise her test adımının 1 kişi tarafından onaylanmasını test sonucu için yeterli görmeleri oldu.

Tabi bütün bu süreçler için hazır şablon belgelerden [5] yararlanıyorlar. Ayrıca her sürüm ile ilgili bilinen hataları ve çözümlerini listeledikleri [6] bir sayfaları mevcut.

Bu testler sırasında düzeltilen hataları NEEDSRETESTING olarak işaretleyerek [7] istekli testçiler tarafından yeniden test edilmesini sağlıyorlar.

Test araçları geliştirme bölümünde farklı kategorilerden araçlar üzerinde çalışıyorlar. Kurulum testleri için SNAKE [8] , python-bugzilla kütüphanesi [9] , ve Bodhi [10] bunlardan öne çıkanlar. Ayrıca test sistemini tam anlamı ile otomatik hale getirecek Breaker [11] aracının geliştirmesi de devam ediyor.

Bu noktada Breaker'ın üzerinde biraz daha durmakta fayda var. Breaker aslında RedHat tarafından kullanılan RHTS [12] aracının Fedora portu. Ancak aracı sadece port etmiyor aynı zamanda bazı özelliklerini ( örneğin test yazımı [13] gibi ) değiştiriyorlar. Test sonuçlarını Spike[14] adındaki bir arayüz ile kaydediyor.

Bittiğinde neredeyse tamamen otomasyona geçirilmiş ( alandığım kadarıyla GUI testleri içinde DogTail [15] entegrasyonu planlıyorlar ) bir test sistemine sahip olacaklar.

RHTS ve DogTail a biraz daha yakından bakacağım sanırım. Belki bu serinin ardından bir seri de otomatik test araçları için yazmak fena olamaz


[1] https://admin.fedoraproject.org/updates/F10/pending
[2] https://admin.fedoraproject.org/updates/metrics/?release=F10
[3] http://fedoraproject.org/wiki/QA/TestPlans/Fedora10Install
[4] http://fedoraproject.org/wiki/QA/TestResults/Fedora10Install/Alpha
[5] http://fedoraproject.org/wiki/QA/TreeTestingTemplate
[6] http://fedoraproject.org/wiki/Bugs/Common
[7] http://feeds.feedburner.com/NeedsRetesting
[8] https://fedorahosted.org/snake/
[9] https://fedorahosted.org/python-bugzilla/
[10] https://fedorahosted.org/bodhi/
[11] http://fedoraproject.org/wiki/QA/Beaker
[12] https://testing.108.redhat.com/wiki/index.php/Rhts
[13] https://testing.108.redhat.com/wiki/index.php/Rhts/Docs/TestWriting
[14] http://developer.spikesource.com/wiki/index.php/Test_Results_Publication_Interface
[15] http://people.redhat.com/zcerza/dogtail/

12 Ocak 2009

Test Dünyasında Neler Oluyor ( Bölüm-2 Mandriva )

Serinin bu bölümünde dünyadaki en yaygın son kullanıcı dağıtımlarından birisi olan Mandriva'nın test ve bununla bağlantılı olarak kararlı depoya paket giriş süreçlerini inceleyeceğiz. Serinin bir önceki yazısını burada bulabilirsiniz.

Sanırım en doğrusu bir paketin kararlı depoya giriş sürecini [1] anlatarak başlamak olacak. Bir paket kararlı olduğuna emin olunan main/updates deposuna alınmak isteniyorsa, paketçi öncelikle bununla ilgili bugzilla raporu açar.

Bu rapor paketin neleri değiştirdiğini ve düzelttiğini anlatan advisory ile nasıl test edilmesi gerektiğini içerir ( örneğin: paketin kapattığı hatayı tekrar eden bir betik ve bunun dışındaki temel işlevleri nasıl test edileceğine dair bilgiler gibi). Hata kaydı kalite güvence takımına atanır( qateam ) ve güvenlik takımı da CC ye alınır ( secteam ). Bu işlemin ardından paket main/testing deposuna alınır.

Kalite-Güvence takımı pakete onay vermemişse ( daha iyi bir test-case yazılması veya uygulamanın kullanımına dair daha detaylı bilgi verilmesi bile olabilir bu ) paketin bakıcısı bu sorunları gidermek zorundadır.

Paketler ile ilgili hatalar tek bir e-posta adresinden giriliyor anladığım kadarıyla bunun amacı mesajlardan bütün takımın haberdar olması ve katkıda bulunabilmesi.

Kalite-Güvence takımdan onay alan paket için ilgili rapor güvenlik takımına atanır. Güvenlik takımı kaynak rpm dosyasını temiz bir sistemde yeniden inşa eder, paket ile ilgili advisory bültenini yayımlar [2] ( bu nokta ilginç aslında, konu güvenlikle ilgili olmasa dahi bütün paketler güvenlik takımından geçiyor ve düzeltme ile ilgili bülten yayımlanıyor ). Bu işlemlerin ardından paket main/updates deposuna alınarak hata kapatılır.

Anladığım kadarıyla güvenlik güncellemeleri ve kritik güncellemeler yukarıdaki politikanın dışında tutuluyor.

Bunun yanı sıra test otomasyonu (buna yarı-otomatik diyelim :) ) için web tabanlı testzilla[3] adlı bir araçtan faydalanıyorlar. Bu aracın temel işlevi testçinin donanım setine uygun olarak test edebileceği paketleri göstermek [4] ve bu paketler ile ilgili raporları girmesini sağlamak.

Asıl otomatik testler yalnız Paris'deki merkez ofiste yapılabiliyormuş. Burada PXE üzerinden başlatılan bilgisayarlara bu iş için özelleştirilen bir sürüm yükleniyor ağ üzerinden ve bu bilgisayarlarda önceden yazılmış test betikleri [5] çalıştırılıyor ve otomatik raporlar üretiliyor bugzillaya girilen.

Bunların yanı sıra bu prosedürleri ve betikleri wikiye aktarıyorlar [6] [7] belirli bir template [8] yapısı içinde.

Son olarak çekirdek testleri için ayrı bir bölüm ayırmışlar [9] ve çekirdek güncellemelerine ayrı bir özenle yaklaşıyorlar. Bu konuda da otomatik test için bir takım araçlardan haberdarlar ancak bunların ne kadarını kullandıklarına dair bir ipucu içermiyor test belgesi.


[1] http://wiki.mandriva.com/en/Policies/Support
[2] http://wiki.mandriva.com/en/2009.0_Errata
[3] http://wiki.mandriva.com/en/Development/Howto/Testzilla
[4] http://cvs.mandriva.com/cgi-bin/viewvc.cgi/testzilla/procedures/NVIDIA/procedure.html?revision=1.5&view=markup
[5] http://cvs.mandriva.com/cgi-bin/viewvc.cgi/testzilla/tests/pamd/valid-pamd-modules.test?revision=1.2&view=markup
[6] http://wiki.mandriva.com/en/Testing
[7] http://wiki.mandriva.com/en/Testing:Bind
[8] http://wiki.mandriva.com/en/Testing:Template
[9] http://wiki.mandriva.com/en/Development/Howto/Test_Update_Candidate_Kernels

6 Ocak 2009

Posted In: mandriva, pardus, test

Twitter Auto Publish Powered By : XYZScripts.com