Türkiye'de bir süredir ülkede alınan patent sayısını arttırmak yönünde çalışmalar yürütülüyor. Özetle "Yaw yayın sayımız tavana vurdu, ama para kazanamıyoruz biz bu işten, bi eksiğimiz patent kaldı, onuda halledersek tamamdır" şeklindeki önermeden yola çıkan bu çalışmalar kapsamında Cuma günü izlediğim bir sunum " Bayh-Dole" yasasının bir benzerinin ülkemizde çıkartılacağı yönündeki hazırlıklardan bahsediyordu.

Temel yaklaşımdaki eksikler atıf sayılarından başlar, ulusal intihal alışkanlığımız ve doçentlik atama kriterlerine kadar uzun bir tartışma konusu olur.

Ancak bahsedilen yasa tasarısı özetle üniversitelerde yapılan tüm çalışmaların patent hakkının öncelikli olarak lüniversiteye ait olmasını buluşu yapan araştırmacının ise bundan pay almasını öngörüyor. Bu durum getirdiği artılar (daha çok patent, patent haklarının kurumsal ölçekte takibi ve satışı vb.) ve eksiler (araştırmacıların demotivasyonu, araştırmacıların kurduğu/ortak olduğu garaj şirketlerinin azalması vb.) daha bir süre tartışılır ancak konu ile ilgili önemli bir saptama var.

Türk Amerikan Bilim İnsanları ve Akademisyenleri Derneği (TASSA: www.tassausa.org) Başkanı Prof. Dr. Banu ONARAL diyor ki:

ABD’de Bayh-Dole Act geçtiğinden beri (1980′ler) kamu desteğiyle yapılan ArGe’den doğan buluşlara üniversitelerin sahip çıkması gerekiyor. Bu görev onların yükümlülüğü. Tüm kamu desteği alan üniversiteler gibi bizim okulumuz da ayni kurala tabi. Yani buluşçularımız üniversitede kurulmuş ‘teknoloji transfer’ ofisinin kanalıyla buluşlarını yola çıkarmak zorundalar.

Kanımca, Türkiye’de fikri hakların korunması ve işlenmesi ‘İnovent’ veya ‘Embrio’ türü girişimci ve kar gayesi güden ve akademik buluşlara odaklanmış firmalar, yerel, yöresel veya ulusal kar gayesi gütmeyen vakıflar ve meslek, işinsanlari veya sektör kuruluşlarının oluşturduğu çok sesli ve çeşitliliği olan bir ‘ekosistem’ kavramıyla süratle yola koyulmalı.”

Daha fazla okuma için bu bağlantıyı takip edebilirsiniz.

Birkaç gündür veri ambarı inşaası ile ilgili çok sayıda doküman okudum. En büyük sıkıntım bu dökümanların daha çok BI sistemlerine odaklanmış olması karar destek sistemleri ve veri madenciliği konularında "bunlar da var" şeklinde özetlenebilecek yaklaşımlarıydı.

Ancak aşağıdaki sunum veri ambarlarının inşaa sürecine ilişkin kavramları düzgün bir şekilde özetlemiş. Öncesinde işin temellerine dair 1-2 döküman okuduysanız konuyu netleştirmek için ideal;

http://www.slideshare.net/idnats/data-warehousing-and-data-mining-presentation-725476

Aslında Gürer'in blog girdisine yorum olarak yazmaya başlamıştım ama laf çok uzayınca bir ayrı bir girdi olarak yazmaya karar verdim.

Sesli düşünmeye çalışacağım. Öncelikle Pardus, Debian ve benzeri dağıtımlardan farklı olarak belirli bir sponsor tarafından finanse edilen, belirli bir büyüklüğe ulaşmış (kanımca kritik eşiği aşmış) ve finanse edilmeye devam edecek bir proje. Bu bağlamda gönüllü geliştiricilerin ayrılması iş gücü olarak ciddi bir kayıp yaratmaz bence.

Hatta bugün bütün gönüllü geliştiriciler ayrılsa dahi projede çok önemsenecek bir değişim yaşanmaz. Projenin kullanıcıları zaten bu tip tartışmaların dışındalar çoğunlukla. Özellikle kurumsal kullanıcılar genel olarak tamamen habersizler camia ve topluluk süreçlerinden.

Eğer ayrılanlar gönüllü geliştiricilerin içerisinde kaliteli bir topluluksa bir süre boyunca gönüllü geliştiricilerin genel kalitesi düşer ancak kritik eşik aşıldığı için durum bir süre sonra normale döner.

Kaybedilecek olan büyüme ölçeklenebilirlik vs. değildir bana göre. İşe bu kavramlardan girilirse, proje yönetimi bunun aksini rakamlarla kısa süre içinde ispat edecektir muhtemelen.

Ama kaybedilen daha değerli bir şeymiş gibi geliyor bana. Maddi olmayan, öyle grafikle tabloyla falan gösterilemeyecek birşeyler. Projeye katkı verirken yaptığı işten zevk alan, bunu yaparken temel motivasyonu özgürlük olan geliştiricilerin kaybedilmesi demek, projenin her durumda ona doğruları çekinmeden söyleyen ve onun özgürlüğünü karşılığında hiçbirşey beklemeden savunan dostlarını kaybetmesi demektir bence.

Hele ayrılanların ardından "Biz süreçlerimizi başkalarına göre mi belirleyeceğiz" ve "Giden gider kalan sağlar bizimdir" türünden yaklaşımlar kalan geliştiricilerle bağları zayıflatmaktan başka bir sonuç doğurmaz. Bu durum değişmediği takdirde bunun sonuçları bugünden yarına da çıkmayacaktır ortaya .

Yalnız kamu ( Başbakanlık, UEKAE, DPT ne dediğiniz fark etmez ) tarafından fonlanan bir proje olduğunu da unutmamak gerekir Pardus'un. Malum devlet de genel olarak sahip olduğu otoriteyi bulabildiği her boşlukta arttırmaya çalışan bir yapıya sahip ülkemizde.

Bu gün özgürlüğü savunan gönüllüler bu projeden kopmaya devam ederse ve projenin büyüklüğüne güvenilip bu durumu değiştirmek için gerekenler yapılmazsa, yarın bu günkü yönetim kadar özgürlük kaygısı olmayan başka birileri bu projenin büyüklüğüne güvenerek ayrılacak 3-5 kişiyi önemsemeyip onu kendi tekellerine aldığında, Pardus'un yalnızca adı ve kodları kalır geriye ve sizin özgürlüğünüzü savunacak kimse kalmamış olabilir ortalıkta. Üstelik bu vaka ilk de olmaz, son da olmaz yalnız ve güzel ülkemde.

Bütün programcılar yazdıkları kodun iyi olmasını ister ancak iyinin neye karşılık geldiğini bulmak zordur genelde. Bu noktada günlük hayattan aldığımız birtakım dersler vardır aklımızda kalan.

Örneğin yazdığımız kodda mümkün olduğunca az hata çıksın isteriz, eğer hata çıkarsa da en kısa zamanda bizim veya başka bir programcının hatayı çözebilmesini isteriz, ürünümüzde bir değişiklik yapacaksak bunu ürünümüzün diğer bileşenlerini mümkün olduğunca az etkilemesiniz isteriz.

Bütün bunlar kurumsal dilde, yazdığımız kodun hatasız, esnek, kararlı, anlaşılır, düşük bakım maliyetine sahip olması demektir. Ancak normal şartlarda bunları ancak yazdığımız kod ürün haline gelip piyasaya çıktığında görebiliyoruz.

İşte tam bu noktada yazılım metrikleri devreye giriyor. Geliştirme esnasında sürekli ölçüm ve iteratif düzeltmeler ile yazılım metriklerini geliştirme sürecinin bir parçası haline getirdiğimizde tasarım ve geliştirme sırasında bize ileride daha büyük maliyetler getirecek pek çok hatadan kurtuluyoruz.

Yazılım mühendisliği ve yazılım kalitesinin ölçümü başlığı altında pek çok kod ölçüm metodu bulunuyor. Bunların hepsini uygulamak pratik olarak çok olası değil, öyleyse bizde piyasada en çok kullanılan metrikleri dikkate alarak bir orta yol bulabiliriz.

Koda dayalı ölçümler

1- Code Coverage
     Yazılan testlerin kodun ne kadarını kapsadığını ölçer. Code coverage için %80 gibi bir oran oldukça iyi görünse de aslında az sayıda basit test yazarak dahi bu orana ulaşılabildiği gözlemlendiği için hedeflenen oranın %100 olması önerilir. (Oran hakkında detaylı bilgi için [1] )

2- Cohesion
    Bu ölçüm sınıfın sorumlu olduğu işlerin kendi içindeki uyumluluğunu ölçer. Her sınıfın tek bir sorumluluğu olmalıdır. [3] [4]. Uyumluluk LCOM (Lack of Cohesion in Methods) adı verilen ölçüt ile bulunur. Değişik türleri bulunan LCOM sınıfta yer alan alanlara metodların ortak erişim sayısını temel alan bir ölçümdür. LCOM3 için bu değer 0 ile 2 arasında değişir ve 1'in üzerindeyse sınıf bölünmelidir. [5]

3- Coupling
    Bir nesnenin diğeri ile etkileşime girmesine denir. Program içerinde mutlaka etkileşim olacaktır, ancak bu ilişkinin nesnelerin implementasyon detaylarından mümkün olduğunca bağımsız olması istenir. Farklı ilişki türleri üzerinden ölçülebilir. En çok kullanılanlardan birisi CBO'dur.
Coupling Between Objects (CBO): Miras alınan sınıflar hariç, sınıfın çalışmak için ihtiyaç duyduğu sınıf sayısıdır. (kısaca importları say :)) Kütüphanelerde bu sayı yüksek olabilir ancak çalıştırılabilir sınıflarda 6 ile 10 arası makul kabul edilebir. [6][9]

4- Cyclomatic Complexity
    Bir metodun içerisinde yer alan karar noktalarının (if, else vb.) sayısıdır. Kabul edilen eşik değer 10'dur.[6] [7] Bunun yanı sıra Essential Complexty denilen bir metrik daha mevcuttur ancak Cyclomatic Complexity'nin daha etkili bir metrik olduğu belirtilmektedir.  [8]

5-  Cyclomatic Density
     Koddaki karar noktalarının toplam çalıştırılabilir koda oranıdır. 0.14 ile 0.42 arasındaki değerler için kodun basit ve anlaşılabilir olduğu kabul edilir.[6]

6- Response For Class (RFC)
    Bir sınıfta yazılan ve çağırılan toplam metotların sayısıdır. Bu değer yükseldikçe kodun bakımı zorlaşır. Önerilen eşik değer 55 dir. [9]

7- Weighted Methods for Class (WMC)
    Bir sınıfta yazılan toplam metot sayısıdır. Eşik değeri olarak 6 ile 33 arasında değişik rakamlar önerilmektedir. Ancak Cohesion değeri WMC'ye kıyasla daha önemlidir. [6] [9]

8-  Class Hierarchy Level veya Depth of Inheritance Tree (DIT)
     Miras ilişkisinde sınıfın üzerinde kaç tane atası olduğunu gösterir. 6'nın üzerinde ise test edilebilirliği çok düşük olduğunu, 2 nin altında ise OO ilkerinin fazla kullanılmadığına işaret eder. Uygulamanın genelinde 2 ve 3 düzeyinde olması hedeflenmelidir. [6]

9-  Number of Methods in Class (NOM)
     İdeal değerler 6 ile 20 arasında değişse de 40'ın üzerinde sınıf kesinlikle bölünmelidir. [6] Ancak tek başına bir gösterge olmaktan çok LCOM ile birlikte değerlendirilmelidir.

10- Specialization Index (SIX)
      Kod karmaşıklığını ve bakım maliyetlerini arttırmasından dolayı overload edilmiş fonksiyon sayısının mümkün olduğunca az olması istenir. Bundan dolayı SIX = (Overload Edilmiş Metot Sayısı * DIT) / NOM şeklinde hesaplanır. 1.2 (veya %120)'ye kadar normal kabul edilir.

* Bunların dışındaki ölçülerden metot başına düşen satır sayısının 7-9 arasında olması tavsiye edilse de Cyclomatic Complexty'nin bundan daha önemli olduğu belirtilmektedir. ([2])

Dizayna dayalı ölçümler [11]

1- Afferent Couplings (Ca)
İncelenen paketin dışında yer aldığı halde söz konusu pakete bağımlı paketlerin sayısıdır. Paketin değişmesi halinde etkilenecek paket sayısını gösterir. Bunu paketin sorumluluğun ölçüsü olarak da düşünebiliriz.

2- Efferent Couplings (Ce)
İncelenen paketin kendi dışında kaç tane pakete bağımlı olduğunu gösterir. Paketin yeniden kullanılabilirliğinin ölçüsüdür.

3- Abstractness (A)
İncelenen pakette yer alan soyut sınıfların ve arayüzlerin sayısının paketteki toplam sınıf sayısına oranıdır. 0 ile 1 arasında değişen bu oran 1'e yaklaştıkça paketin esnekliği artar.

4- Instability (I)
I = Ce / (Ce + Ca) şeklinde hesaplanır. 0 ile 1 arasında değişen bu oran 1'e yaklaştıkça paketin kararlılığı azalır. (Yani paketin değişimi sistemdeki başka pek çok paket üzerinde değişiklik yapmayı gerektirir.)

Devam etmeden küçük bir not girelim araya. Karalılık genelde iyi yönde yorumlansa da bir paketin tamamen kararlı olması demek paketin değiştirilebilirliğinin de minimum düzeyde olması anlamına gelir. Bu durumda hangi paketlerin esnek hangi paketlerin daha az esnek ama kararlı yapıda olmasını istediğimizi sorgulamalıyız. Bu konuda cevabı bize "Open/Closed Principle" veriyor. Buna göre yazılımı oluşturan birimler geliştirilmeye açık ancak değiştirilmeye kapalı olmalıdır. Bu noktada hangi tür sınıflar geliştirilmeye açık diye bakarsak soyut sınıfları ve arayüzleri görürüz.

Sonuca bakarsak; Abstractness = 1 ve Instability = 0 olduğu durumda hem kararlı hem de değiştirilebilir paketleri buluruz. Aynı biçimde Abstractness = 0 ve Instability = 1 olduğu durumda ise kararsız ancak değişime kapalı (ve böylece başka paketlerin değişimini gerektirmeyecek) durumdaki paketleri buluruz.

Ancak incelediğimiz paketler her zaman bu iki ideal durumdan birinde olmazlar. Bu durumda bu iki değerin dengede olması yani ;(A,I) = (1,0) dan (0,1) e gittikçe aynı miktarda değişmesi tasarımımız için optimal çözüm olarak görülebilir. Bunu grafiksel olarak ifade edersek;


Main Sequence denilen bu çizgi üzerinde yer alan bütün noktaları ideal noktalar kabul ettiğimize göre bunların dışında elde ettiğimiz değerleri bu çizgiye olan uzaklıklarına göre değerlendirebiliriz. Tasarım veya yeniden yapılandırma sırasındaki amacımız paketlerimizin bu çizgi üzerinde ve çizgiye en yakın durumda olmasıdır.

5- Distance from the Main Sequence (D)
D = |A+I-1| ile hesaplanır ve 0 ile 1 arasında değişir. 0 olması analiz edilen pakete ait değerin Main Sequence çizgisinin üzerinde olması demektir.

Bunların yanı sıra kod tekrar sayısı ile dizayn ve kod izlenebilirliği de dikkate alınması gereken unsurlardır. Kod tekrarı için bütün proje içerisinde kod tekrarı yapılan bölümler tesbit edilerek uygun biçimde (ortak sınıflar, soyut sınıflar, arayüzler) yeniden tasarlanmalıdır. Dizayn ve Kod izlenebilirliği ise (Tasarım belgelerinde yer alan birimlerin, uygulamadaki birimlere (sınıf,modül vb.) oranı) de yazılımın kalitesini belirleyenbir unsur olarak görülebilir.

[1] http://codebetter.com/blogs/patricksmacchia/archive/2009/06/07/high-test-coverage-ratio-is-a-good-thing-anyway.aspx

[2] http://stackoverflow.com/questions/312642/how-many-classes-per-package-methods-per-class-lines-per-method

[3] http://www.cihataltuntas.com/?p=111

[4] http://en.wikipedia.org/wiki/Single_responsibility_principle

[5] http://javaboutique.internet.com/tutorials/coupcoh/

[6] http://www.mccabe.com/pdf/McCabeCodeQualityMetrics-OutsourcedDev.pdf

[7] http://javaboutique.internet.com/tutorials/metrics/

[8] http://www.nasa.gov/centers/ivv/ppt/172536main_Mike_Chapman_The_Relationship_of_Cyclomatic_Complexity_Essential_Complexity_and_Error_Rates.ppt

[9] http://www.issre2009.org/archive/2006_supplemental/student_papers/An_Investigation_of_CK_Metrics_Thresholds.pdf

[10] http://support.objecteering.com/objecteering6.1/help/us/metrics/metrics_in_detail/specialization_index.htm

[11] http://www.objectmentor.com/resources/articles/oodmetrc.pdf

So after a week I finally start to see the big picture for BDD. And here is the roadmap for a beginner on BDD. I think it'll be helpful on the road.


İntroduction to Behavior Driven Development
http://dannorth.net/introducing-bdd
http://behaviour-driven.org/
http://en.wikipedia.org/wiki/Behavior_driven_development


Jbehave2 Basics
http://jbehave.org/documentation/two-minute-tutorial/
http://www.bitmotif.com/java/jbehave-rave/


Jbehave2 Selenium and Matchers
http://blog.m.artins.net/tag/jbehave/


Jbehave2 Validations
http://www.testearly.com/2007/07/16/using-bdd-to-drive-development/


Mockito is your friend ( Also Jbehave's best friend )
http://code.google.com/p/mockito/wiki/FeaturesAndMotivations
http://mockito.googlecode.com/svn/branches/1.7/javadoc/org/mockito/Mockito.html


Deeper Jbehave2
http://www.ibm.com/developerworks/java/library/j-cq09187/


Deeper Jbehave2 Part-2 ( Some codes are misssing in the tutorial )
http://www.ryangreenhall.com/articles/bdd-by-example.html


Behavior Driven Database Development
http://www.methodsandtools.com/archive/archive.php?id=78

Ayrılık hep zor gelmiştir bana. Hele bir de bunu bloglamak istediğinizde işiniz daha da zorlaşıyormuş.
Fazla uzatmamaya çalışacağım. 18 aydır profesyonel olarak yaptığım Pardus geliştiriciliğini artık amatör olarak sürdüreceğim.

Yeni işime bu gün başladım ama bu başka bir yazıya kalsın. Bütün bu macera boyunca tanıdığım, hepsinin bilgilerinden vizyonundan faydalandığım tüm ekip arkadaşlarıma, en zor zamanlarda camiamızı organize edip yardıma gelen Oi ekibine ve bu süre boyunca pek çok sorunda beraber çalıştığımız bir çoğunu yalnız ismen tanıdığım camia üyelerimize her şey için çok teşekkür ederim.

Nedense kelimeler akmıyor ekrana klavyeden, en iyisi şimdilik burada kesmek.

"So long and thanks for all the fish"

Bu serinin son bölümünü Ubuntu oluşturuyor. Şu ana kadar incelediğim dağıtımlar arasında en iyi test süreçlerine sahip olanı mıdır emin değilim ama bu konudaki en iyi dokümantasyona sahip dağıtım olduğunu söyleyebilirim.

Ubuntu QA takımına ait 2 farklı anasayfa bulunuyor [1] [2] , bunlardan ikincisi bu girdi yazıldığı tarihte henüz tam olarak aktif değildi. Alt QA takımlarına ait siteler henüz işlerlik kazanmamıştı.

Bu nokta da QA takımına biraz daha yakından bakalım. Ubuntu QA takımı aktif olarak iş yapmaktan çok QA ile ilgili iş yapan ekiplerin kordinasyonundan sorumlu. Hata ayıklamak (çözmek değil), Testler, Brainstorm arayüzü gibi değişik pek çok alandan sorumlu QA takımı.

Hata Ekibi'nin [3] yaptığı işler ayrı bir yazı konusu olabilecek kadar fazla olduğundan burada detay vermeyi düşünmüyorum. Asıl sorumluluğunu hata sınıflandırmak olarak tanımlayabileceğimiz ekip bu başlık altında hataları uygun kişilere atama, hataları birbiri ile ve upstream ile eşleştirme, Bütün hataların istenilen temel bilgileri içermesini sağlamak, hata onaylamak gibi pek çok işi yapıyor. [4] [5]

* Pardus tarafına baktığımızda gönüllü sayısının azlığından dolayı aynı kişiler ile işler yürüyecek olsa da organizasyon olarak test ve hata ayıklama işlerini birbirinden ayrıştırmak mantıklı göründü bana da.

Gelelim Ubuntu Test Takımına; Takımın ana sayfası [6] oldukça düzenli ve özet bilgileri içeriyor. Öncelikle bir TODO listeleri bulunuyor [7] yapılacak işleri özetleyen. Bunun yanında bir sonraki sürümde yapılacak işler için de ayrı bir yol haritası [8] tutuyorlar.

Güncellemelerden çok yeni çıkacak sürümün testlerine yoğunlaşmış durumdalar, 6 aylık sürüm periyotları olduğunu düşünürsek bu çok garipsenecek bir durum değil aslında. Güncelleme testlerini ayrıca inceleyeceğiz, öncelikle sürüm testlerine bakalım.

Sürüme kadar olan süreçte oldukça fazla sayıda ön sürüm çıkartıyorlar ( Örneğin bu yazı yazıldığı tarihte 4 tane Alfa sürümü mevcuttu ). Testler için ayrı bir makina veya disk ayrılmasını istiyorlar.

Testler 2 safhada gerçekleşiyor. İlki Smoke Test [9] adı verilen ara sürüm çıkmadan önceki 4-5 günlük periyotta gerçekleşen testler. Bu testlerde herbir ara sürüm için show-stopper olan sürümün temel işlevlerini test ediyorlar. [10]

Ara sürümün çıkmasının ardından ise image validation olarak adlandırılan daha geniş kapsamlı testlere geçiliyor.

Testlerin raporlanmasını Launchpad üzerinden ISO Tracker [11] adındaki bir web uygulaması ile gerçekleştiriliyor. ISO Tracker ile güncelleme yolu ile sürüm yükselten testçilerin test etmesi mümkün olmayan ISO üzerinden farklı biçimlerdeki kurulum alternatifleri test ediliyor ve hatalar raporlanıyor. Burada Launchpad in merkezi hata takip yapısının sunduğu avantajlardan faydalanılarak yeni hata girişi ve var olan hataların takibi kolaylıkla mümkün olabiliyor. Bunun yanı sıra ISO testlerindeki onay bekleyen hataları da wiki aracılığı ile listeliyorlar. [12]

Bunun dışında kalan testler için uyguladıkları metodlara ait dokümanlara ulaşamadım ancak kullandıkları test yönergelerine [13] ulaşılabiliyor. Ayrıca bu test caselerin neleri kapsadığını görebilmekte güzel. [14] Bu noktada son olarak dikkatimi çeken bölüm eklenecek olan yeni özelliklere ilişkin herşey ( uygulamasından testine kadar ) wiki aracılığı ile detaylı bir biçimde paylaşılıyor. [15]

Şimdi de sürüm içi güncelleme testlerine bakalım. Bu testler konusunda oldukça hassas davranıyor Ubuntu. Her güncellemeyi almıyor kararlı sürüme [16] ( Sık sürüm çıkartmanın bir başka avantajı ) genellikle çok önemli bir hatayı çözüyor olması gerekiyor. Hatta güvenlik güncellemelerinde bile aynı seçilikle yaklaşıyor [17] kararlı sürüm güncellemelerine.

Bu süreçlerin her ikisinde de özel durumlar haricinde sürüm güncellemesi yapmıyor, sadece hatayı çözen yamayı mümkün olduğunca minimal bir şekilde backport ediyorlar.

Gelelim bizim için asıl önemli nokta olan güncelleme prosedürüne;

1- Öncelikle hatanın o anki geliştirme sürümünde düzeltildiğinden emin olunur.

2- Güncellemenin çözdüğü hata raporuna gerekli açıklama girilir. Bu açıklamada hatanın etkileri, geliştirme sürümünde nasıl çözüldüğü, hatanın nasıl tekrarlanabileceği ve yamanın yaratabileceği olası yan etkiler anlatılır. Ayrıca hatayı çözen minimal yama da eklenir. Eğer bu yamayı hazırlamak çok uzun bir süre alacaksa SRU ( Stable Release Updates ) takımından onay alınır ( anladığım kadarıyla sürüm güncellemesi için alınıyor bu onay ).

3- Paket aday olarak işaretlenir ve SRU takımına haber verilir. Yöneticiler tarafından onaylanan paket derlenir ve test edilmek için hazır hale gelir.

4- SRU onaylama takımı açık olan verification-needed etiketli hataları [18] düzenli olarak inceler ve onay veya ret kararı verir.


[1] https://wiki.ubuntu.com/QATeam
[2] http://qa.ubuntu.com/
[3] https://wiki.ubuntu.com/BugSquad
[4] https://wiki.ubuntu.com/Bugs/HowToTriage/
[5] https://wiki.ubuntu.com/Bugs/HowToTriage/Charts
[6] https://wiki.ubuntu.com/Testing
[7] https://wiki.ubuntu.com/Testing/TODO
[8] https://wiki.ubuntu.com/QATeam/RoadMap
[9] https://wiki.ubuntu.com/Testing/ISO/Schedule
[10] https://wiki.ubuntu.com/Testing/ISO/Smoke
[11] http://iso.qa.ubuntu.com/qatracker/
[12] https://wiki.ubuntu.com/Testing/FixesToVerify
[13] http://testcases.qa.ubuntu.com/
[14] http://testcases.qa.ubuntu.com/Coverage/Overview
[15] https://wiki.ubuntu.com/EncryptedPrivateDirectory
[16] https://wiki.ubuntu.com/StableReleaseUpdates#When
[17] https://wiki.ubuntu.com/SecurityUpdateProcedures
[18] http://people.ubuntu.com/~ubuntu-archive/pending-sru.html

Bir süredir Pardus'un test işlerinden mesul-üm. Bu zaman zarfında, zaman zaman başka projelerin test işlerini nasıl yürüttüğüne göz atmış olsam da bütün projeleri kapsayan detaylı bir inceleme yapmak vardı aklımda. Test dünyasında işler nasıl yürüyor ? Başkalarından daha iyi olduğumuz yönler neler , nerelerde eksiklerimiz var ? Daha kaliteli bir dağıtım için neleri değiştirebiliriz ? gibi sorulara yanıt arayacağım. Derlediğim bilgilerde gözden kaçan, yanlış anladığım noktalar varsa düzeltmenizden memnun olurum.

Pardus

Daha önce biraz bahsetmiştim test süreçlerimizden. Bu vesile ile güncel değişiklikleri de katarak kısaca özetleyeyim.

Pardus'da Test süreçlerimiz 2 ana kategoriye ayrılıyor; Sürüm öncesi testler ve Sürüm içi testler. Bunlara dair detaylı bilgi wiki sayfamızda mevcut. Bir önceki yazının yazıldığı zamandan bu yana yapılan önemli bir değişiklik ise sürüm içi testleri artık gönüllülerimizle beraber yapıyor olmamız.

Bir sonraki adım da ise hata raporlarına bir onay mekanizması getirerek bu konudaki sorumluluğu da gönüllülerimizle paylaşmayı planlamaktayız.

OpenSuse

Görebildiğim kadarıyla yalnızca bir sonraki sürüme ilişkin test süreçleri mevcut. Kararlı sürüme girecek paketleri/yamaları ne şekilde test ediyorlar buna dair bir bilgiye rastlayamadım.

Geliştirme sürümlerini "Factory" namı ile anıyorlar. Bu sürüme dair yaklaşık 6 aylık yol haritaları belli. Ayrıca ara sürümler arasındaki önemli değişiklikleri de özet halinde yayımlıyorlar [1] Test sonuçlarını bugzilla üzerinden hata girerek raporluyorlar.

Hata takip sistemine nasıl hata girileceğine ilişkin oldukça detaylı dökümantasyona [2] [3] sahipler.

Bu noktaya kadar genel olarak bizden iyi durumdalar. Ama bu konular direkt olarak ilgilendirmiyor test süreçlerini.

Çok basit düzeyde temel test yönergeleri bulunuyor benim baktığım an itibariyle [4] . Bu konuda çok başarılı olduklarını söyleyemeyeceğim. Dağıtımı test etmeye yönelik temel süreçlerde bizim kadar detaylı bir planları yok. Ancak çok detaylı bir yol haritaları olduğu için değişen ve yeni gelen özellikleri test etmek konusunda oldukça detaylı bir çalışma yapmışlar.

İlginç gelen bir diğer nokta da mobil cihazlar ile olan senronizasyona ayrı bir bölüm ayırmışlar.

Son olarak da otomatik test araçları ile ilgili bir takım planları olduğu anlaşılıyor ki, bu araçları inceleyeceğim ayrı bir girdi yazmak niyetindeyim.

Edit: OpenSuse test süreçleri ile ilgili yeni bulduğum bir takım bilgileri eklemek istedim; Öncelikle Depo ve test politikalarını tanımlayan açık bir belge bulunmuyor. Uzun aramaların ardından kalite takımından Holger böyle bir belgeleri bulunmadığını yazdı.

Kalite takımı demişken, 43 kişiden oluşan ( Novel çalışanı ) bir test takımları var. Açık olarak yazmıyor ama benim tahminim bu ekip sadece OpenSuse için değil Aynı zamanda SLES içinde çalışıyor.

Oldukça geniş bir araçseti kullanıyorlar testler için, liste aşağıda mevcut

• Bonnie.............................• Module Loading
• Buildcrunch...................• Newburn
• DBench...........................• Netperf
• FTPload..........................• NIC Bonding
• File System Stress.........• Process Stress
• LMbench .......................• Sched Stress
• LTP.................................• Reaim
• Memeater......................• Tiobench
• Memtester

Test otomasyonu için HAMSTA adlı bir araçları var ki aslında bu yerel test araçları için bir çeşit framework. Bunun yanı sıra test planlaması içinde Testopia'dan faydalanıyorlar. Ancak bu araç gereğinden fazla karmaşık göründü bana.

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/

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

Pardus ekibine katıldığımdan beri pek fırsat bulamıyorum yazmaya. Oldukça yoğun ama bir o kadar da zevkli bir çalışma dönemi yaşıyoruz.

Sorumlusu olduğum Pardus test süreçlerinden bahsetmek istedim biraz. Hem süreçleri çekirdek ekip dışındakiler için biraz daha belirgin kılmak, hem de Pardus Test Takımına ve gelecekteki takım arkadaşlarımıza bir başlangıç noktası oluşturmak için.

Pardus ekibinin her üyesinde görebileceğiniz ortak bir özellik mükemmeliyet takıntısıdır. Bazen küçük bir düğmenin yeri ve işlevi için bile saatlerce tartışabiliyoruz. Ancak Pardus'la ilgili değerlendirmeleri okudukça harcadığımız bu zamanın karşılığını fazlası ile aldığımızı görüyoruz. Pardus Test Takımı da bu mükemmelleştirme sürecinin önemli bir parçası olmak üzere kuruldu.

Ne kadar yetenekli geliştiricilere sahip olursanız olun, tek başına sorunsuz çalışan parçalar bir araya gelince çalışmak konusunda sorun yaratabiliyorlar. Pardus Test Takımının görevi büyük yapbozu incelemek ve onu kusursuz hale getirmek.

Evvel zaman içinde, Pardus 1.0 sürümü öncesinde rootfs in çıkışı ile başlamış test takımı kurma fikri. O zamanki adıyla Resmi Pardus Test Sürecinin (RPTS) kordinasyonunu sevgili Erkan Tekman yürütüyormuş. Lakin zaman içinde iş yoğunluğunun arasında kaybolmuş gitmiş yeni sürümler çıkarken RPTS. Bu gün bu süreç daha geniş bir katılımla ve daha uzun soluklu olarak yeniden canlanıyor.

Yeni test sürecini planlarken önce diğer dağıtımların test süreçlerini inceledik. Kendi çalışma metoçlarımızı gözden geçirdik. Geçmişteki deneyimlerimize dönüp baktık. Sonuçta test süreçlerinin 2 ana bölüme ayrılmasına karar verdik.

Test takımımız şimdilik birinci bölümde bizlere yardımcı olacak ancak süreç ilerledik takımın içinde çıkacak istekli ve tecrübeli arkadaşlarla ikinci bölümü de bir ekip halinde yürütmeyi planlıyoruz.

Birinci Bölüm "Sürüm Öncesi Test Süreci"

Sürüm Öncesi Test Süreci alfa sürümünün çıkması ile başlayan ve kararlı sürüm ile sona eren yaklaşık 30 - 60 günlük bir süreçtir. Bu süreç de Alfa , Beta ve RC sürümleri çıktıkça, test takımımız kendileri için hazırlanan test kılavuzunun yardımıyla dağıtımın temel işlevlerini test edecek ve sonuçları test_takımı listesi aracılığı ile bizimle paylaşacaklar. Liste içinde istenilen bilgilerin tamamlanması ile gerekiyorsa hata takip sistemine aktarılacak hata bilgileri ve burada çözümlendikten sonra hatayı bildiren ve tekrarlayan takım üyelerince çözüm onaylanacak.

İkinci Bölüm "Düzenli Testler"

Bu test süreci yeni kararlı sürümün çıkması ile başlar ve sürüm resmi olarak desteklendiği sürece devam eder. Bu süreçte kendi içinde ikiye ayrılır. "Güncelleme Testleri" ve "İşlev Testi".

Bu süreç için öncelikle, test edilen kararlı sürüm ( örneğin Pardus-2007 ) ve o ana kadar çıkmış ara sürümlerin her birinin ( örneğin 2007.1 , 2007.2 , 2007.3 ) yeni kurulmuş birer versiyonuna sahip olmamız gerekir. Her bir testin ardından tekrar bu temiz kurulumlara ihtiyaç duyacağımızdan bu sürümleri sanal görüntü olarak kurmak ( misal VirtualBox ile ;) ) sağlık ve de sıhhat açısından faydalıdır. Bu sanal görüntüleri güncelleme testlerinde kullanacağız.

Ayrıca her güncelleme sonrasında kararlı depodan güncellediğimiz düzenli güncellenen bir sanal imaja da ihtiyaç vardır.

Süreç genel hatları ile şöyle işler; Test sorumlusu test deposunda bekleyen paketler için bir onay süreci başlatır. Geliştiriciler tarafından onaylanan paketler o anki kararlı depo ve onay alan yeni paketlerden oluşan bir geçici depoya aktarılırlar. Temiz kurulmuş sürümlere bu deponun adresi verilerek sürümler güncellenir. Her güncellenmiş sürüm yeniden başlatılarak temel sistemlerin sağlıklı işleyip işlemediği kontrol edilir. Ardından revdep-rebuild komutu ile ters bağımlılıklardaki kırık paylaşımlı kütüphane dosyalarının varlığı denetlenir.

İşlev testi içinse, kararlı depo ile eş zamanlı güncellediğimiz imaj, test için geçici depodan güncellenir ve güncellenen her bir program tek tek test edilir.

Testçinin bütün program ve kütüphaneleri bütün özellikleri ile test etmesi bilgi, tecrübe ve zaman açısından mümkün görülmediği için test edilecek olan paketler 4 ana kategoriye ayrılmıştır. Kategorizasyon işlemi halen devam etmekte olup yeterince olgunlaşınca wikiye aktarılacak. Bu kategoriler; Detaylı biçimde test edilecek paketler ( ki bunların nasıl test edileceği ayrıntılı olarak belgelenmiştir ) , Standart biçimde test edilecek paketler ( kurulum ve temel çalışma denetimi yapılır ) , Yalnız kurulum testine tabi tutulacak paketler ve Multimedya paketleridir ( Multimedya paketlerininde nasıl test edileceği detaylı olarak belgelenmiştir ).

Bu süreçler Pardus'un dünyada ve Türkiye'de hak ettiği yere gelmesinde önemli rol oynarken bizlere de test takımımızın içinden yeni dostlar ve yeni geliştiriciler kazandıracak. Özgürlük İçin...

Uzun zamandır bir şeyler karalamadığımı düşünecek olursak aslında anlatılacak çok şey var. Ancak daha önemli konular var. Camia yı takip edenler bir süredir OOXML ve TSE'nin bu konudaki tavrı konusundaki log girdilerini ve e-postaları görmüşlerdir. Bende bu girdilerden ve postalardan yararlanarak bilgi edinme yasası gereği cevaplanmak üzere bir takım sorular yönelttim TSE ye. Gelen cevapları yayınlayacağım. Bu şekilde yeterince fazla kişi soru sorar ise en azından dikkati çekilebilir TSE'nin diye düşünüyorum. Gönderdiğim bilgi edinme isteğinin tam metni ise aşağıda;

Sayın Yetkili,

Elektronik ortamdaki dokümantasyon için açık standartların belirlenmesi konusundaki sorunların çözümü için şubatta Cenevre'de yapılacak olan "Ballot Çözüm Toplantısı" (Ballot Resolution Meeting) na ve TSE nin bu toplantıda ne şekilde tavır alacağına ilişkin bir takım sorularım olacak. 4982 Sayılı Bilgi Edinme Kanunu uyarınca bu soruların cevaplanmasını arz ederim.

1- Cenevre'deki Ballot Çözüm Toplantısı'nda (DIS 29500) TSE'yi kim temsil edecek?

2- Toplantıya ülkemiz adına katılacak olan delegeler, Microsoft'tan yeterince bağımsız mı?

3- TSE'nin sorumlu komitesi 3500 çözüm önerisi veya hepsi değilse bile sadece gönderdikleri ulusal açıklamalar üzerinde çalışıyor mu?

4- TSE temsilcisinin Micrsoft'un önerdiği standart olan OOXML lehine oy kullanacağı yönündeki bilgiler doğru mudur ? ( Lütfen ekdeki apora bakınız )

5- Eğer 4. sorunun cevabı evet ise TSE temsilcileri aşağıdaki durumların farkında mıdır ? Ve bu konuların varlığına rağmen Microsoft'un görüşleri lehinde oy kullanmayı halen düşünmekte midir ?

a- Microsoft'un sunduğu belgede OOXML sistemi içersinde yer alan bir çok
maddenin sadece "isimleri" belirtilmiş ama bu maddeler tanımlanmamıştır.
Microsoft bu bilgeleri kendine saklamakta ve kesin bir tanım vermeyi
reddetmektedir.

b- Bir başka durum ise Microsoft'un gönderme yaptığı standartları açık olarak
bildirmemesi. Örneğin bir karakter kümesinin birden fazla sürümü olduğu
durumda Microsoft bu karakter kümesinin hangi sürümüne gönderme yaptığını
bildirmemiştir. Bu durumda A kişisi ürettiği bir belgeyi iki farklı
arkadaşına yolladığı zaman bu iki kişi aynı belgeyi sadece farklı editörler
kullandıkları için özgün halinden başka bir şekilde görebilirler.

c-Microsoft OOXML standardında kullanacağını beyan ettiği bazı alt sistemleri
kendi patenti altında barındırmaktadır. Bu durumun en vahim sonucu Microsoft
patentlerinin kullanım hakkına sahip olmadan OOXML formatlı bir belgenin
açılmasının mümkün olmamasıdır. Microsoft bu belgede bu teliflerin kamunun
kullanımına açılıp açılmayacağı konusunda herhangi bir açıklamada
bulunmamıştır.

d- Microsoft OOXML ile ne yazık ki plartform bağımsız bir standart yaratmaktan
çok uzakta bir noktadadır. Bu haliyle OOXML ancak Windows ortamında ve ancak
Office programı aracılığı ile tam ve verimli olarak kullanılabilecek gibi
görünmekte. Diğer editörler (örneğin OpenOffice) OOXML formatlı belgeleri ya
hiç açamayacak ya da açabilseler bile özgün belgenin görünüm ve içeriğinden
çok farklı ve sorunlu bir şekilde görüntüleme imkanı sunacaktır.

* Bu şiir, Hakkari - Çukurca - Üzümlü Jandarma Sınır Karakolu'nda görevliyken 12 Aralık 1993 günü saat 21.00 sıralarında bölücü eşkiya ile yapılan silahlı çatışmada şehit düşen Jandarma Komando Onbaşı Zekeriya Gülyaman'ın şahsi eşyaları içerisinden çıkmıştır.

Başlıkta gördüğünüz deyim henüz literatüre girmedi. Ama yakında girecektir zannımca ben de isim babası olayım istedim. Sebebini buradan okursunuz.

Not: Bu arada çeşitli mecralarda "devlet işletim sistemi geliştireceğine o parayı yazılımcılara teşvik olarak verse memleket ihya olurdu" diye yırtınan bir takım lamer bozmaları ile yardakçılarının gözü aydın. Buyrun bakalım alın teşviklerinizi de ne geliştirecekmişsiniz bizler de bir görelim.

Odatv.com adlı haber televizyonu ( haber sitesi değil ) yayına başladı.Soner Yalçın ve Cüneyt Özdemir tarafından kurulan televizyonun bilindiği kadarı ile hiçbir medya grubu ile direkt bağlantısı yok. Televizyondan ilginç bir haberde aşağıda.

Bu görüntü Irak işgaline katılan İngiliz askerlerinin kamerasından yansıyor. Kendi jeeplerinin içinde arkadan gelen arabalara rastgele ateş ediyorlar. Arkadan gelen arabaları vurduklarında seviniyor, vuramadıklarında üzülüyorlar.

Kendimi dakika başı blog yaza asosyal bir adam gibi hissetmeye başladım ama bunları yazmazsam çatlarım ;)

Bu aralar ev bakıyorum İstanbul'da. Gördüğüm ev ilanlarından biri aklıma bu günlerin beynelminel sorusunu getirmedi desem yalan olur "Türkiye Malezya Olur Mu ?" :)

Bir diğer konuda bilişim suçlarıyla ilgilenen ÜST DÜZEY bir emniyet yetkilisine birileri, Youtube un Türkiye temsilciliğinin olamayacağını çünkü şirketin hali hazırda Google'a ait olduğunu ve Google ında uzun bir süredir Türkiye ofisi bulunduğunu söylemeli artık.


Not: Tabi habertürk ün röpörtajı %100 hayali de olabilir. Güzide basınımızdan beklenecek bir davranış.

Bir köşe yazısı için pek çok sıfat kullanılabilir. Ancak bazı yazılar vardır ki beylik sıfatlarla değil ancak sıra dışı kelimelerle tanımlanabilir.

Örneğin bugün okuduğum bir yazı [1], üzerinde yoğun kıvamlı mantar sosu bulunan, kolay kesilip, her bir lokması neredeyse çiğnenmeden ağızda eriyen Chateaubriand tadı hissettirdi bana.



Yazının tamamı ilgili bağlantıda mevcut ancak ben size beğendiğim yerlerden birkaç dilim keseyim;

Üniversiteyi anlamak için “neden eski Yunan’da?” sorusuna yanıt bulmalıyız. “Agora kültürü” dediğimiz meydanda serbest tartışma alışkanlığı önemliydi. “Mythostan logosa dönüşüm” yani dünyayı açıklamak için mitolojiler yerine rasyonaliteden yararlanmaya başlamak dönüm noktası. Böylece seküler düşünce ve eleştirel akıl ortaya çıkıyor. İşte felsefenin ve üniversitenin etkileşimi böyle başlıyor.

Fikir platformunda bütün düşüncelerin özgürce tartışılabilmesi ve “Agora kültürü”nün günümüze uyarlanması umut edilir. Devletlerden statükoyu koruması beklenirken, üniversitenin değişimin öncüsü olması arzu edilir. Sadece bilgi ile beslenen, “memur zihniyetinin dışında duruşu olan” akademik dünya üyelerinin kültür, etik ve dünya görüşü bakımından daima ileriye bakan ve hep yeni araşıylar içinde olan kişiler olması esastır.

Neyse efendim fazla vaktinizi almadan sizi bu lezzetli yazıyla başbaşa bırakayım.

[1]