tag:blogger.com,1999:blog-73200052024-03-14T01:30:31.172+03:00Serbülent Ünsal'ın Web GünlüğüUnknownnoreply@blogger.comBlogger124125tag:blogger.com,1999:blog-7320005.post-90472662687922133282014-07-01T18:18:00.000+03:002014-07-01T18:43:47.282+03:00Bir Takım Geçişken Şeyler<br />
İnsanın hayatında pis rezil olduğu durumlar vardır. Gavur bunu WTF moment olarak havalı bir biçimde söylese de yurdum insanı "astir bea" olarak daha net anlaşılır hale getirmiştir bu olguyu.<br />
<br />
Neyse efendim, bendeniz de dün itibariyle benzer bir anı yaşadım ve bu girdiyi yazmak şart oldu kendime ceza kabilinden. Burada resim puslanır sahne siyah beyaza döner ve olaylar şöyle gelişir;<br />
<br />
Doktora aday adayımız giriş mülakatına girmek üzere 12 saatlik bir yolculuğun ardından ülkemizin tanınmış üniversitelerinden birine ulaşır. Mülakat saatine kadar araştırma konusu ile ilgili jüri hocalarının yazdığı makaleleri ve kitap bölümlerini okuyarak kendince özgüven depolamaktadır, gelişecek olaylara pek bir hazır olduğunu sanmaktadır.<br />
<br />
Derken, mülakat saati gelir lakin, her toplumsal sıralama olayında olduğu gibi olay olması gereken vakitte cereyan etmemekte ısrarlıdır. Mülakat salonu önünde beklemekten sıkıldığı bir anda telefonla konuşmaktadır ki, adı okunur ve kahramanımız telefonunu aceleyle kapatıp olay mahalline intikal eder. <br />
<br />
Salona girdiğinde karşısında 6 kişilik bir jüri vardır (WTF moment 1). 6 ya 1 eşitsizliği ilk başta kahramanımızın gözünü korkutsa da, çocukluğu "Kara Murat" serisini izleyerek geçmiş esas oğlanı yıldırmaz bu durum.<br />
<br />
Yüksek lisans çalışmalarını kısaca özetlemesinin ardından bir South Park sessizliği oluşmuşken, yüksek lisans jürisinde bulunan bir hoca malum soruyu sorar;<br />
<br />
"Sana yüksek lisans jürisinde bir soru sormuştum, hatırladın mı ?"<br />
<br />
(Hatırladım lakin hatırlamak istemiyorum, çünkü bildiğin cevaplayamayıp mal gibi kalmıştım)<br />
<br />
"Hatırladım hocam" der kahramanımız. Hoca işin peşini bırakmamaktadır;<br />
<br />
"Baktın mı sınavdan sonra çözümüne sorunun ?"<br />
<br />
"Baktım hocam" der esas oğlan. <br />
<br />
(Baktın ama yetmez) der hoca içinden ve bu ses dışarı şöyle yansır;<br />
<br />
"Anlat bakalım o zaman, difüzyon denklemlerinde neden ikinci derece türev kullanılır !!! "<br />
<br />
"Bakın şimdi hocam, basitçe anlatmak gerekirse geçişen (diffuse) eden maddemizin ilgilendiğimiz bölümünü bir araba gibi düşünelim. Biliyoruz ki bir arabanın hareketini hesaplarken birinci derece türev bize hızı , ikinci derece türev ise hızdaki değişimi (hızlanma/acceleration) verir. Bizim derdimiz t anında x konumunda olduğunu bildiğimiz arabanın t+1 anında nerede olduğunu bulabilmekse eğer, hız ki, biz buna halk arasında birinci dereceden türev deriz bizim için tek başına birşey ifade etmez çünkü; arabamız t anından t+1 anı arasında hızlanmış veya yavaşlamış olabilir, arabanın hızının bu zaman aralığında nasıl değiştiğini bulmak için Anadolu'da ikinci dereceden türev olarak adlandırılan matematiksel işleme ihtiyaç duyarız."<br />
<br />
Bu konu aşağıdaki videoda detaylı olarak açıklanmıştır ve dahi tam ekran olarak izlemeniz tavsiye edilir;<br />
<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<iframe allowfullscreen='allowfullscreen' webkitallowfullscreen='webkitallowfullscreen' mozallowfullscreen='mozallowfullscreen' width='320' height='266' src='https://www.youtube.com/embed/9dfUhhpkagU?feature=player_embedded' frameborder='0'></iframe></div>
<br />
<br />
"Aslında bu konuyu matematiksel olarak Fick kanunları (ki onlar iki tanedir) ile açıklayabiliriz. Moleküllerin bir bölgeden diğer bölgeye geçişine akı der ve bunu J ile gösterirsek akıyı zamandan bağımsız olarak<br />
<br />
<div style="text-align: center;">
<blockquote class="tr_bq">
<blockquote class="tr_bq">
<blockquote class="tr_bq">
<blockquote class="tr_bq">
<blockquote class="tr_bq">
<blockquote class="tr_bq">
<blockquote class="tr_bq">
<img src="http://latex.codecogs.com/gif.latex?J=&space;-D\frac{\delta&space;C}{\delta&space;x}" title="J= -D\frac{\delta C}{\delta x}" /> </blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</div>
<br />
şeklinde ifade edebiliriz. Burada D ilgilendiğimiz molekülün difüzyon katsayısı C derişim ve x molekülün katettiği mesafeyi gösterir. Bu kanun zamandan bağımsız olarak, derişimi farklı, iki bölge arasındaki geçişi ifade eder ve bu geçiş çok yoğun bölgeden az yoğun bölgeye doğru derişimler eşitlenene kadar devam eder."<br />
<br />
"Fick birinci kanununda zaman mefhumunu ihmal edip benim bu soruya sonsuza kadar cevap verebilme şansım varmış gibi davranırken, gerçek durum böyle değildir. Aslında bu soruyu hiç cevaplamayıp doktora yeterlilikte bu soruyu sormanızı garanti altına almak ve daha sınava girmeden bir soru fazla cevaplayarak zamanı bükmek istesem de bunun evrende yol açacağı kaostan korktuğumdan bu ihtimali hızla eliyor ve konuya kaldığım yerden devam ediyorum"<br />
<br />
"Neyse, yaptığı eşşekliğin farkına varan Fick "Achtung" der yani "Ben ne yaptım". Bunun üzerine ikinci kanununu yazar,<br />
<br />
<div style="text-align: center;">
<img src="http://latex.codecogs.com/gif.latex?\frac{\delta&space;C}{\delta&space;t}&space;=&space;\frac{\delta&space;J}{\delta&space;x}" title="\frac{\delta C}{\delta t} = \frac{\delta J}{\delta x}" /> </div>
<br />
bu noktada akının kendisi hesaplanmaya muhtaç bir dede kaldı ki gayrıya himmet ede diye düşünen Fick bruder J yi birinci denklemden getirip yerine koyarak<br />
<br />
<div style="text-align: center;">
<img src="http://latex.codecogs.com/gif.latex?\frac{\delta&space;C}{\delta&space;t}&space;=&space;-D\frac{\delta^{2}&space;C}{\delta&space;x^{2}}" title="\frac{\delta C}{\delta t} = -D\frac{\delta^{2} C}{\delta x^{2}}" /> </div>
<br />
denklemini elde eder. Bu da neden 2. dereceden türev sorusunun daha kitabi bir açıklamasını sunar bize"<br />
<br />
<br />
Diyemedim ya la...<br />
<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<iframe allowfullscreen='allowfullscreen' webkitallowfullscreen='webkitallowfullscreen' mozallowfullscreen='mozallowfullscreen' width='320' height='480' src='https://www.youtube.com/embed/rZlK6hjf8iw?feature=player_embedded' frameborder='0'></iframe></div>
Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-7320005.post-68183065475312686592012-09-17T01:47:00.001+03:002012-09-17T01:47:50.072+03:00Yeni Eğitim Öğretim Yılı Kutlu OlsunHer maaş zammında her hak ihlalinde seslerini seslerini yükseltiyor öğretmenler. İşte o zaman aklımdan geçiyor, "Öğretmenler haftada 15 saat çalışıyor sonra yatıyor" diyen bu günün muktedir nesillerini kimler yetiştirdi diye ?<br />
<br />
Sadece 1-2 kişi olsa bunu söyleyen 5-10 tane yaptığı işin hakkını vermeyen öğretmeni suçlayabilirsiniz ama bunu söyleyen muktedirlerin çevresinde onlat gibi düşünen başka muktedirler var, onların etrafında onlardan nemalanmak için onlar gibi görünmekteyen çekinmeyen başka yarı muktedirler mevcut. Çemberin bir dış halkasında ise bunlar bizden diyerek kendi çıkarlarına aykırı işler yapsalarda bunu görmek istemeyen oy kaynakları bulunuyor.<br />
<br />
E hocam bunları topla çarp böl memleketin %50'si ediyor. Ha kalan %50 nin ne kadarı kendi tercihleri iktidarda olsa daha farklı davranır o da ayrı bir konu.<br />
<br />
Bu kadar insanın düşünmeyi, dürüstlüğü, sevgiyi, hoşgörüyü, doğruyu savunurken - haksızlığa uğradığında dik durmayı, kimsenin hakkını yemeden hakkını savunmayı öğrenmeden yetişmesinde hiç mi payı yok işlerini müfredat defterinden öte görmeyen öğretmenlerin ? <br />
<br />
Size başka bir öğretmenin hikayesini anlatmak isterdim ama uzun uzun anlatsam biliyorum ki o utanır övüldüğü için. Çünkü istese çok daha yüksek ücretlerle çalışabileceği kimya mühendisliğini bırakıp kimya öğretmenliğini seçtiğinde ve yıllarca sabırla öğrenci yetiştirdiğinde aklında alacağı övgüler yoktu.<br />
<br />
Ne kadar anlamsız gelmişti lise yıllarımızda parayı değil öğretmenliği seçmesi. Ama zaten bütün seçimleriyle şaşırttı bizi. Sınıfta arkadaşına tokat atan öğrenciyi tokatla terbiye etmeyi seçebilecek iken bütün beyefendiliği ile "<i>Egonuzu tatmin ettiyseniz yerinize oturur musunuz ?</i>" diyerek utanmayı öğretirken de, Pınar Su etiketinin arkasındaki içeriği sınavda verip "<i>hadi bakalım ph değerini bulun</i>" derken de, "<i>Zeytin yağından yapılan sabun nasıl oluyorda yağı çözüyor</i>" diye sorarken de, Sınavda kopya çekenlerin çektiği kopyaların yüzüne söyleyip tam not verirken de hep farklıydı ve sadece düşünmeyi değil, hayata karşı insanca durmayı da öğretmeye çalışıyormuş Ethem Hocam.<br />
<br />
Belki bu günden sonra öğretmenler sınıfın kapısını her açışlarında sadece kendi geleceklerini değil, kendi çocuklarının ve ülkede yaşayacak diğer bütün insanların geleceğini de şekillendiriyor olduklarını fark ederler bir ihtimal. Çokça ortada gezinen klişe yazıları sevmem ama <strong style="font-weight: normal;">Haim Ginott'tan bir alıntı ile bitsin bu yazı da;</strong><br />
<br />
<blockquote class="tr_bq">
<strong style="font-weight: normal;"> Bir toplama kampından sağ kurtulmuş bir insanım. Gözlerim, hiçbir insanın görmemesi gereken şeyleri gördü.</strong> </blockquote>
<blockquote class="tr_bq">
<strong style="font-weight: normal;">Bilgili mühendisler tarafından yapılan gaz odaları. İyi eğitim görmüş doktorlar tarafından zehirlenen çocuklar. Eğitilmiş hemşireler tarafından öldürülen bebekler. Lise ve yüksekokul mezunları tarafından vurularak öldürülen kadınlar ve bebekler.</strong> </blockquote>
<blockquote class="tr_bq">
<strong style="font-weight: normal;"> Bu nedenle, öğrenim olgusuna kuşkuyla bakıyorum. Sizden tek dileğim şudur: Öğrencilerinize insan olmayı öğretin. Çabalarınız bilgili canavarlar, yetenekli ruh hastaları ya da eğitilmiş Eichmann'lar yaratmamalı. Okuma-yazma, yazım, tarih ve matematik, ancak öğrencilerimizin insan olmasını sağlarsa önem kazanırlar.</strong></blockquote>
Unknownnoreply@blogger.com1tag:blogger.com,1999:blog-7320005.post-4413536628444743052012-03-31T20:37:00.003+03:002012-03-31T20:42:41.320+03:00Türkiyede Patentler ÜzerineTü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 "<b> Bayh-Dole</b>" yasasının bir benzerinin ülkemizde çıkartılacağı yönündeki hazırlıklardan bahsediyordu.<br />
<br />
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.<br />
<br />
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.<br />
<br />
Türk Amerikan Bilim İnsanları ve Akademisyenleri Derneği (TASSA: <a href="http://www.tassausa.org/" title="blocked::http://www.tassausa.org/ http://www.tassausa.org/">www.tassausa.org</a>) Başkanı Prof. Dr. Banu ONARAL diyor ki:<br />
<br />
<div>
<i>“Bildiğiniz gibi bilginin ve bilimin ekonomik değere dönüşmesi
çok kapsamlı ve doğal olarak çok yönlü gelişmiş bir ‘ekosistem’
gerektiriyor. Fikri haklar ve yatırım sermayesi bu düzenin önemli
öğeleri.</i></div>
<i>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.</i><br />
<i> </i><br />
<div>
<i>Bilginin ticari ürüne dönüşmesi yolunda atılan bu adımın
yararları kadar zararları da var. Girişimci ve stratejik üniversitelerde
açılan bu tür merkezler (Stanford, MIT…) veya mezunların önderliğinde
kurulan vakıflar (Wisconsin Univ’de WARF) başarılara imza atarken,
bürokratik (yani riskten korkan) ve daha kötüsü hiyerarşik
(emir-kumanda) yapılı devlet veya özel üniversiteler adeta buluş
mezarlıkları haline geliyorlar. Ayrıca, girişimcilik ruhuyla ve
işbilgisi ve deneyimi ile yaklaşılmayan fikri haklar portfolyosunun
bakımı ve pazarlanması müthiş masraflı bir hale geliyor. Üniversitelere
yük oluyor… Ve kısır döngünün çarkları dönmeye başlıyor.</i></div>
<i>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ı.”</i><br />
<br />
Daha fazla okuma için <a href="http://www.kaandericioglu.com/2010/05/universite-ogretim-elemanlarinin-buluslari/">bu</a> bağlantıyı takip edebilirsiniz.<br />
<b></b>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-7320005.post-19349867855316319382011-07-16T16:46:00.000+03:002011-07-16T16:46:11.069+03:00Veri madenciliği için Veri Ambarları İnşaası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ı.<br />
<br />
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;<br />
<br />
http://www.slideshare.net/idnats/data-warehousing-and-data-mining-presentation-725476<br />
<br />
<br />
<br />Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-7320005.post-71619432948109159092010-08-16T15:53:00.002+03:002010-08-16T15:53:34.184+03:00<div><a href="http://supernaturalfanwiki.wetpaint.com/page/Which+Supernatural+Character+Are+You%3F"><img alt="Which Supernatural Character are you?" border="0" src="http://image.wetpaint.com/image/3/Z5HYNqSCRTujKadSAO3xKQ212649/GW230H230" /></a><br />
<small>Take the <a href="http://supernaturalfanwiki.wetpaint.com/page/Which+Supernatural+Character+Are+You%3F">Supernatural Character Quiz</a></small></div>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-7320005.post-11010378795695816372010-07-11T21:53:00.001+03:002010-07-12T08:29:33.816+03:00Özgür Kuşlar Üzerine...Aslında Gürer'in <a href="http://6kere9.com/blag/2010/07/11/75/">blog girdisine</a> yorum olarak yazmaya başlamıştım ama laf çok uzayınca bir ayrı bir girdi olarak yazmaya karar verdim.<br /><br />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.<br /><br />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.<br /><br />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.<br /><br />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.<br /><br />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.<br /><br />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 .<br /><br />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.<br /><br />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 <a href="http://cadde.milliyet.com.tr/2010/07/06/YazarDetay/984590/Bir_bilim_adami__bir_bilim_adamini_anlatiyor___"> ilk de olmaz, son da olmaz</a> yalnız ve güzel ülkemde.Unknownnoreply@blogger.com4tag:blogger.com,1999:blog-7320005.post-34042561957371628912010-05-29T11:27:00.004+03:002010-05-29T19:06:41.261+03:00Kod Kalite Ölçümleri ve Sık Kullanılan MetriklerBütün programcılar yazdıkları kodun <b>iyi </b>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.<br />
<br />
Ö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.<br />
<br />
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.<br />
<br />
İş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.<br />
<br />
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.<br />
<i><u><b><span style="font-size: small;"><br />
<span style="font-size: large;">Koda dayalı ölçümler</span></span></b></u></i><br />
<i><u><b><span style="font-size: small;"><span style="font-size: large;"> </span></span></b></u></i><br />
<b>1- Code Coverage</b><br />
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] )<br />
<br />
<b>2- Cohesion</b><br />
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 (<span class="ContentBody">Lack of Cohesion in Methods</span>) 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]<br />
<br />
<b>3- Coupling </b><br />
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.<br />
<span class="ContentBody"><b>Coupling Between Objects (CBO): </b>Miras alınan sınıflar hariç, sınıfın çalışmak için ihtiyaç duyduğu</span> 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]<br />
<br />
<b>4- Cyclomatic Complexity</b><br />
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]<br />
<br />
<b>5- Cyclomatic Density</b><br />
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]<br />
<br />
<b>6- Response For Class (RFC)</b><br />
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]<br />
<br />
<b>7- Weighted Methods for Class (WMC)</b><br />
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 <b>Cohesion</b> değeri WMC'ye kıyasla daha önemlidir. [6] [9]<br />
<br />
<b>8- Class Hierarchy Level veya<a href="http://draft.blogger.com/post-create.g?blogID=7320005" id="concepts" name="concepts"></a> Depth of Inheritance Tree (DIT)</b><br />
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]<br />
<br />
<b>9- Number of Methods in Class (NOM)</b><br />
İ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.<br />
<br />
<b>10- Specialization Index (SIX)</b><br />
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.<br />
<br />
* 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])<br />
<br />
<span style="font-size: small;"><i><u><b><span style="font-size: large;">Dizayna dayalı ölçümler [11]</span></b></u></i></span><br />
<br />
<b>1- Afferent Couplings (Ca) </b><br />
İ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.<br />
<b> </b><br />
<b>2- Efferent Couplings (Ce) </b><br />
İncelenen paketin kendi dışında kaç tane pakete bağımlı olduğunu gösterir. Paketin yeniden kullanılabilirliğinin ölçüsüdür.<br />
<b> </b><br />
<b>3- Abstractness (A)</b><br />
İ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.<br />
<b> </b><br />
<b>4- Instability (I)</b><br />
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.)<br />
<br />
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.<br />
<br />
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.<br />
<br />
Ancak incelediğimiz paketler her zaman bu iki <b>ideal</b> 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;<br />
<br />
<div style="text-align: center;"><div id="ilu-" style="text-align: center;"><span style="font-size: small;"><i><a href="https://docs.google.com/File?id=dxf6czc_69ch8pm6dp_b" target="_blank"><img src="https://docs.google.com/File?id=dxf6czc_69ch8pm6dp_b" style="height: 252.422px; width: 320px;" /></a></i></span></div></div><br />
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.<br />
<br />
<b> 5- Distance from the Main Sequence (D)</b><br />
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.<br />
<br />
Bunların yanı sıra<b> kod tekrar sayısı </b><span style="font-size: small;">ile</span> <b>dizayn ve kod izlenebilirliği</b> 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.<br />
<br />
[1] <a href="http://codebetter.com/blogs/patricksmacchia/archive/2009/06/07/high-test-coverage-ratio-is-a-good-thing-anyway.aspx">http://codebetter.com/blogs/patricksmacchia/archive/2009/06/07/high-test-coverage-ratio-is-a-good-thing-anyway.aspx</a><br />
<br />
[2] <a href="http://stackoverflow.com/questions/312642/how-many-classes-per-package-methods-per-class-lines-per-method">http://stackoverflow.com/questions/312642/how-many-classes-per-package-methods-per-class-lines-per-method</a><br />
<br />
[3] <a href="http://www.cihataltuntas.com/?p=111">http://www.cihataltuntas.com/?p=111</a><br />
<br />
[4] <a href="http://en.wikipedia.org/wiki/Single_responsibility_principle">http://en.wikipedia.org/wiki/Single_responsibility_principle</a><br />
<br />
[5] <a href="http://javaboutique.internet.com/tutorials/coupcoh/">http://javaboutique.internet.com/tutorials/coupcoh/</a><br />
<br />
[6] <a href="http://www.mccabe.com/pdf/McCabeCodeQualityMetrics-OutsourcedDev.pdf">http://www.mccabe.com/pdf/McCabeCodeQualityMetrics-OutsourcedDev.pdf</a><br />
<br />
[7] <a href="http://javaboutique.internet.com/tutorials/metrics/">http://javaboutique.internet.com/tutorials/metrics/</a><br />
<br />
[8] <a href="http://www.nasa.gov/centers/ivv/ppt/172536main_Mike_Chapman_The_Relationship_of_Cyclomatic_Complexity_Essential_Complexity_and_Error_Rates.ppt">http://www.nasa.gov/centers/ivv/ppt/172536main_Mike_Chapman_The_Relationship_of_Cyclomatic_Complexity_Essential_Complexity_and_Error_Rates.ppt</a><br />
<br />
[9] <a href="http://www.issre2009.org/archive/2006_supplemental/student_papers/An_Investigation_of_CK_Metrics_Thresholds.pdf">http://www.issre2009.org/archive/2006_supplemental/student_papers/An_Investigation_of_CK_Metrics_Thresholds.pdf</a><br />
<br />
[10] <a href="http://support.objecteering.com/objecteering6.1/help/us/metrics/metrics_in_detail/specialization_index.htm">http://support.objecteering.com/objecteering6.1/help/us/metrics/metrics_in_detail/specialization_index.htm</a><br />
<br />
[11] <a href="http://www.objectmentor.com/resources/articles/oodmetrc.pdf">http://www.objectmentor.com/resources/articles/oodmetrc.pdf</a>Unknownnoreply@blogger.com3tag:blogger.com,1999:blog-7320005.post-11637549860849661432009-08-31T14:36:00.000+03:002009-08-31T14:36:06.227+03:00Oi & Fortigate ailesi<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj5CVEHBNi4M4I_eJg-J5u3Hsui582XpUtfaVvZNEtfZFQb4y-vO9KPMcEJYRec-zqwzCImSmE1qOG2g7gqZ92t4sUJ36VN73ICAgb3pmFtwFAPSq3vmsDIb92E7y2Mm7d-W6E2aw/s1600-h/snapshot1.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj5CVEHBNi4M4I_eJg-J5u3Hsui582XpUtfaVvZNEtfZFQb4y-vO9KPMcEJYRec-zqwzCImSmE1qOG2g7gqZ92t4sUJ36VN73ICAgb3pmFtwFAPSq3vmsDIb92E7y2Mm7d-W6E2aw/s400/snapshot1.png" /></a></div>Unknownnoreply@blogger.com5tag:blogger.com,1999:blog-7320005.post-20739754423007235132009-06-26T14:32:00.003+03:002009-06-26T14:38:42.213+03:00BDD (Behavior Driven Development) RoadmapSo 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.<br><br /><br /><span style="font-weight: bold;">İntroduction to Behavior Driven Development</span><br />http://dannorth.net/introducing-bdd<br />http://behaviour-driven.org/<br />http://en.wikipedia.org/wiki/Behavior_driven_development<br><br /><br /><span style="font-weight: bold;">Jbehave2 Basics</span><br />http://jbehave.org/documentation/two-minute-tutorial/<br />http://www.bitmotif.com/java/jbehave-rave/<br><br /><br /><span style="font-weight: bold;">Jbehave2 Selenium and Matchers</span><br />http://blog.m.artins.net/tag/jbehave/<br><br /><br /><span style="font-weight: bold;">Jbehave2 Validations</span><br />http://www.testearly.com/2007/07/16/using-bdd-to-drive-development/<br><br /><br /><span style="font-weight: bold;">Mockito is your friend ( Also Jbehave's best friend )</span><br />http://code.google.com/p/mockito/wiki/FeaturesAndMotivations<br />http://mockito.googlecode.com/svn/branches/1.7/javadoc/org/mockito/Mockito.html<br><br /><br /><span style="font-weight: bold;">Deeper Jbehave2</span><br />http://www.ibm.com/developerworks/java/library/j-cq09187/<br><br /><br /><span style="font-weight: bold;">Deeper Jbehave2 Part-2 ( Some codes are misssing in the tutorial )</span><br />http://www.ryangreenhall.com/articles/bdd-by-example.html<br><br /><br /><span style="font-weight: bold;">Behavior Driven Database Development</span><br />http://www.methodsandtools.com/archive/archive.php?id=78Unknownnoreply@blogger.com1tag:blogger.com,1999:blog-7320005.post-68734662177872233682009-06-15T19:26:00.002+03:002009-06-15T19:58:40.485+03:00Demir almak günü gelmişse zamandan...Ayrılık hep zor gelmiştir bana. Hele bir de bunu bloglamak istediğinizde işiniz daha da zorlaşıyormuş.<br />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.<br /><br />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.<br /><br />Nedense kelimeler akmıyor ekrana klavyeden, en iyisi şimdilik burada kesmek.<br /><br />"So long and thanks for all the fish"Unknownnoreply@blogger.com7tag:blogger.com,1999:blog-7320005.post-42890544458917926922009-02-09T13:48:00.012+02:002009-02-13T15:37:38.629+02:00Test Dünyasında Neler Oluyor ( Bölüm-4 Ubuntu )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.<br /><br />Ubuntu QA takımına ait 2 farklı anasayfa bulunuyor <a href="https://wiki.ubuntu.com/QATeam">[1]</a> <a href="http://qa.ubuntu.com/">[2]</a> , 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ı.<br /><br />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ı.<br /><br />Hata Ekibi'nin <a href="https://wiki.ubuntu.com/BugSquad">[3]</a> 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. <a href="https://wiki.ubuntu.com/Bugs/HowToTriage/">[4]</a> <a href="https://wiki.ubuntu.com/Bugs/HowToTriage/Charts">[5]</a><br /><br /><span style="font-weight: bold;">* 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.</span><br /><br />Gelelim Ubuntu Test Takımına; Takımın ana sayfası <a href="https://wiki.ubuntu.com/Testing">[6]</a> oldukça düzenli ve özet bilgileri içeriyor. Öncelikle bir TODO listeleri bulunuyor <a href="ttps://wiki.ubuntu.com/Testing/TODO">[7]</a> yapılacak işleri özetleyen. Bunun yanında bir sonraki sürümde yapılacak işler için de ayrı bir yol haritası <a href="https://wiki.ubuntu.com/QATeam/RoadMap">[8]</a> tutuyorlar.<br /><br />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.<br /><br />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.<br /><br />Testler 2 safhada gerçekleşiyor. İlki Smoke Test <a href="https://wiki.ubuntu.com/Testing/ISO/Schedule">[9]</a> 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. <a href="https://wiki.ubuntu.com/Testing/ISO/Smoke">[10]</a><br /><br />Ara sürümün çıkmasının ardından ise image validation olarak adlandırılan daha geniş kapsamlı testlere geçiliyor.<br /><br />Testlerin raporlanmasını Launchpad üzerinden ISO Tracker <a href="http://iso.qa.ubuntu.com/qatracker/">[11]</a> 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. <a href="https://wiki.ubuntu.com/Testing/FixesToVerify">[12]</a><br /><br />Bunun dışında kalan testler için uyguladıkları metodlara ait dokümanlara ulaşamadım ancak kullandıkları test yönergelerine <a href="http://testcases.qa.ubuntu.com/">[13]</a> ulaşılabiliyor. Ayrıca bu test caselerin neleri kapsadığını görebilmekte güzel. <a href="http://testcases.qa.ubuntu.com/Coverage/Overview">[14]</a> 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. <a href="https://wiki.ubuntu.com/EncryptedPrivateDirectory">[15]</a><br /><br />Ş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 <a href="https://wiki.ubuntu.com/StableReleaseUpdates#When">[16]</a> ( Sık sürüm çıkartmanın bir başka avantajı ) genellikle çok önemli bir hatayı çözüyor olması gerekiyor. Hatta <span style="font-weight: bold;">güvenlik güncellemelerinde</span> bile aynı seçilikle yaklaşıyor <a href="https://wiki.ubuntu.com/SecurityUpdateProcedures#Issues%20that%20warrant%20a%20security%20update">[17]</a> kararlı sürüm güncellemelerine.<br /><br />Bu süreçlerin her ikisinde de özel durumlar haricinde <span style="font-weight: bold;">sürüm güncellemesi yapmıyor</span>, sadece hatayı çözen yamayı mümkün olduğunca minimal bir şekilde <span style="font-weight: bold;">backport </span>ediyorlar.<br /><br />Gelelim bizim için asıl önemli nokta olan güncelleme prosedürüne;<br /><br />1- Öncelikle hatanın o anki geliştirme sürümünde düzeltildiğinden emin olunur.<br /><br />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 ).<br /><br />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.<br /><br />4- SRU onaylama takımı açık olan <tt class="backtick">verification-needed </tt>etiketli hataları <a href="http://people.ubuntu.com/%7Eubuntu-archive/pending-sru.html">[18]</a> düzenli olarak inceler ve onay veya ret kararı verir.<br /><br /><br />[1] https://wiki.ubuntu.com/QATeam<br />[2] http://qa.ubuntu.com/<br />[3] https://wiki.ubuntu.com/BugSquad<br />[4] https://wiki.ubuntu.com/Bugs/HowToTriage/<br />[5] https://wiki.ubuntu.com/Bugs/HowToTriage/Charts<br />[6] https://wiki.ubuntu.com/Testing<br />[7] https://wiki.ubuntu.com/Testing/TODO<br />[8] https://wiki.ubuntu.com/QATeam/RoadMap<br />[9] https://wiki.ubuntu.com/Testing/ISO/Schedule<br />[10] https://wiki.ubuntu.com/Testing/ISO/Smoke<br />[11] http://iso.qa.ubuntu.com/qatracker/<br />[12] https://wiki.ubuntu.com/Testing/FixesToVerify<br />[13] http://testcases.qa.ubuntu.com/<br />[14] http://testcases.qa.ubuntu.com/Coverage/Overview<br />[15] https://wiki.ubuntu.com/EncryptedPrivateDirectory<br />[16] https://wiki.ubuntu.com/StableReleaseUpdates#When<br />[17] https://wiki.ubuntu.com/SecurityUpdateProcedures<br />[18] http://people.ubuntu.com/~ubuntu-archive/pending-sru.htmlUnknownnoreply@blogger.com0tag:blogger.com,1999:blog-7320005.post-76161987015144893252009-01-12T15:04:00.002+02:002009-01-12T16:48:49.439+02:00Test 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.<br /><br /><br /><span style="font-style: italic; font-weight: bold;">Hata sınıflandırma</span> bölümünde hataların doğru insanlara atanmasını sağlıyorlar.<br /><br /><span style="font-weight: bold; font-style: italic;">Güncelleme testlerini </span>Bodhi <a href="https://admin.fedoraproject.org/updates/F10/pending">[1]</a> 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 <a href="https://admin.fedoraproject.org/updates/metrics/?release=F10">[2]</a>. 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ı.<br /><br /><span style="font-weight: bold; font-style: italic;">Sürüm testleri</span> ü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.<br /><br />Sürüm testleri için oldukça detaylı bir test planına sahipler <a href="http://fedoraproject.org/wiki/QA/TestPlans/Fedora10Install">[3]</a> 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.<br /><br />Bu kategorideki test sonuçlarını pek renkli fakat hoş bir tablo üzerinden takip ediyorlar <a href="http://fedoraproject.org/wiki/QA/TestResults/Fedora10Install/Alpha">[4]</a> . 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.<br /><br />Tabi bütün bu süreçler için hazır şablon belgelerden <a href="http://fedoraproject.org/wiki/QA/TreeTestingTemplate">[5]</a> yararlanıyorlar. Ayrıca her sürüm ile ilgili bilinen hataları ve çözümlerini listeledikleri <a href="http://fedoraproject.org/wiki/Bugs/Common">[6]</a> bir sayfaları mevcut.<br /><br />Bu testler sırasında düzeltilen hataları NEEDSRETESTING olarak işaretleyerek <a href="http://feeds.feedburner.com/NeedsRetesting">[7]</a> istekli testçiler tarafından yeniden test edilmesini sağlıyorlar.<br /><br />Test araçları geliştirme bölümünde farklı kategorilerden araçlar üzerinde çalışıyorlar. Kurulum testleri için SNAKE <a href="https://fedorahosted.org/snake/">[8]</a> , python-bugzilla kütüphanesi <a href="https://fedorahosted.org/python-bugzilla/">[9]</a> , ve Bodhi <a href="https://fedorahosted.org/bodhi/">[10]</a> bunlardan öne çıkanlar. Ayrıca test sistemini tam anlamı ile otomatik hale getirecek Breaker <a href="http://fedoraproject.org/wiki/QA/Beaker">[11]</a> aracının geliştirmesi de devam ediyor.<br /><br />Bu noktada Breaker'ın üzerinde biraz daha durmakta fayda var. Breaker aslında RedHat tarafından kullanılan RHTS <a href="https://testing.108.redhat.com/wiki/index.php/Rhts">[12]</a> aracının Fedora portu. Ancak aracı sadece port etmiyor aynı zamanda bazı özelliklerini ( örneğin test yazımı <a href="https://testing.108.redhat.com/wiki/index.php/Rhts/Docs/TestWriting">[13]</a> gibi ) değiştiriyorlar. Test sonuçlarını Spike<a href="http://developer.spikesource.com/wiki/index.php/Test_Results_Publication_Interface">[14]</a> adındaki bir arayüz ile kaydediyor.<br /><br />Bittiğinde neredeyse tamamen otomasyona geçirilmiş ( alandığım kadarıyla GUI testleri içinde DogTail <a href="http://people.redhat.com/zcerza/dogtail/">[15] </a>entegrasyonu planlıyorlar ) bir test sistemine sahip olacaklar.<br /><br />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<br /><br /><br />[1] https://admin.fedoraproject.org/updates/F10/pending<br />[2] https://admin.fedoraproject.org/updates/metrics/?release=F10<br />[3] http://fedoraproject.org/wiki/QA/TestPlans/Fedora10Install<br />[4] http://fedoraproject.org/wiki/QA/TestResults/Fedora10Install/Alpha<br />[5] http://fedoraproject.org/wiki/QA/TreeTestingTemplate<br />[6] http://fedoraproject.org/wiki/Bugs/Common<br />[7] http://feeds.feedburner.com/NeedsRetesting<br />[8] https://fedorahosted.org/snake/<br />[9] https://fedorahosted.org/python-bugzilla/<br />[10] https://fedorahosted.org/bodhi/<br />[11] http://fedoraproject.org/wiki/QA/Beaker<br />[12] https://testing.108.redhat.com/wiki/index.php/Rhts<br />[13] https://testing.108.redhat.com/wiki/index.php/Rhts/Docs/TestWriting<br />[14] http://developer.spikesource.com/wiki/index.php/Test_Results_Publication_Interface<br />[15] http://people.redhat.com/zcerza/dogtail/Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-7320005.post-80314566660324773102009-01-06T19:30:00.004+02:002009-01-06T22:42:32.851+02:00Test 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ı <a href="http://nightwalkers.blogspot.com/2008/09/test-dnyasnda-neler-oluyor-blm-1.html">burada</a> bulabilirsiniz.<br /><br />Sanırım en doğrusu bir paketin kararlı depoya giriş sürecini <a href="http://wiki.mandriva.com/en/Policies/Support">[1]</a> anlatarak başlamak olacak. Bir paket kararlı olduğuna emin olunan <span style="font-style: italic;font-family:courier;color:blue;" >main/updates </span>deposuna alınmak isteniyorsa, paketçi öncelikle bununla ilgili bugzilla raporu açar.<br /><br />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 <span style="font-style: italic;font-family:courier;color:blue;" >main/testing</span> deposuna alınır.<br /><br />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.<br /><br />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. <br /><br />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 <a href="http://wiki.mandriva.com/en/2009.0_Errata">[2] </a>( 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 <span style="font-style: italic;font-family:courier;color:blue;" >main/updates </span>deposuna alınarak hata kapatılır.<br /><br />Anladığım kadarıyla güvenlik güncellemeleri ve kritik güncellemeler yukarıdaki politikanın dışında tutuluyor.<br /><br />Bunun yanı sıra test otomasyonu (buna yarı-otomatik diyelim :) ) için web tabanlı testzilla<a href="http://wiki.mandriva.com/en/Development/Howto/Testzilla">[3]</a> 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 <a href="http://cvs.mandriva.com/cgi-bin/viewvc.cgi/testzilla/procedures/NVIDIA/procedure.html?revision=1.5&view=markup">[4]</a> ve bu paketler ile ilgili raporları girmesini sağlamak.<br /><br />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 <a href="http://cvs.mandriva.com/cgi-bin/viewvc.cgi/testzilla/tests/pamd/valid-pamd-modules.test?revision=1.2&view=markup">[5]</a> çalıştırılıyor ve otomatik raporlar üretiliyor bugzillaya girilen.<br /><br />Bunların yanı sıra bu prosedürleri ve betikleri wikiye aktarıyorlar <a href="http://wiki.mandriva.com/en/Testing">[6]</a> <a href="http://wiki.mandriva.com/en/Testing:Bind">[7]</a> belirli bir template <a href="http://wiki.mandriva.com/en/Testing:Template">[8]</a> yapısı içinde.<br /><br />Son olarak çekirdek testleri için ayrı bir bölüm ayırmışlar <a href="http://wiki.mandriva.com/en/Development/Howto/Test_Update_Candidate_Kernels">[9]</a> 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.<br /><br /><br />[1] http://wiki.mandriva.com/en/Policies/Support<br />[2] http://wiki.mandriva.com/en/2009.0_Errata<br />[3] http://wiki.mandriva.com/en/Development/Howto/Testzilla<br />[4] http://cvs.mandriva.com/cgi-bin/viewvc.cgi/testzilla/procedures/NVIDIA/procedure.html?revision=1.5&view=markup<br />[5] http://cvs.mandriva.com/cgi-bin/viewvc.cgi/testzilla/tests/pamd/valid-pamd-modules.test?revision=1.2&view=markup<br />[6] http://wiki.mandriva.com/en/Testing<br />[7] http://wiki.mandriva.com/en/Testing:Bind<br />[8] http://wiki.mandriva.com/en/Testing:Template<br />[9] http://wiki.mandriva.com/en/Development/Howto/Test_Update_Candidate_KernelsUnknownnoreply@blogger.com0tag:blogger.com,1999:blog-7320005.post-80476745119773131092008-09-01T22:23:00.001+03:002009-01-20T11:51:43.064+02:00Test Dünyasında Neler Oluyor... (Bölüm 1)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.<br /><br />Pardus<br /><br />Daha önce biraz <a href="http://nightwalkers.blogspot.com/2008/04/pardus-test-srecinin-dn-bugn-yarn.html">bahsetmiştim</a> test süreçlerimizden. Bu vesile ile güncel değişiklikleri de katarak kısaca özetleyeyim.<br /><br />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 <a href="http://tr.pardus-wiki.org/Pardus_Test_G%C3%B6n%C3%BCll%C3%BCs%C3%BC_Olmak">wiki sayfamızda</a> 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.<br /><br />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.<br /><br />OpenSuse<br /><br />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.<br /><br />Geliştirme sürümlerini "Factory" namı ile anıyorlar. Bu sürüme dair yaklaşık <a href="http://en.opensuse.org/Roadmap/11.1">6 aylık yol haritaları belli.</a> Ayrıca ara sürümler arasındaki önemli değişiklikleri de özet halinde yayımlıyorlar <a href="http://en.opensuse.org/Factory/News">[1]</a> Test sonuçlarını bugzilla üzerinden hata girerek raporluyorlar.<br /><br />Hata takip sistemine nasıl hata girileceğine ilişkin oldukça detaylı dökümantasyona <a href="http://www.blogger.com/1">[2]</a> <a href="http://en.opensuse.org/Bug_Reporting_FAQ">[3]</a> sahipler.<br /><br />Bu noktaya kadar genel olarak bizden iyi durumdalar. Ama bu konular direkt olarak ilgilendirmiyor test süreçlerini.<br /><br />Çok basit düzeyde temel test yönergeleri bulunuyor benim baktığım an itibariyle <a href="http://en.opensuse.org/index.php?title=Testing&action=edit&section=4">[4]</a> . 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 <a href="http://en.opensuse.org/Testing:Features_11.0">yapmışlar</a>.<br /><br />İlginç gelen bir diğer nokta da mobil cihazlar ile olan senronizasyona ayrı bir bölüm <a href="http://en.opensuse.org/OpenSync/SyncML-OBEX-Client">ayırmışlar</a>.<br /><br />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.<br /><br />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ı.<br /><a href="http://en.opensuse.org/QA_Team"><br />Kalite takımı </a>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.<br /><br />Oldukça geniş bir araçseti kullanıyorlar testler için, liste aşağıda mevcut<br /><br />• Bonnie.............................• Module Loading<br />• Buildcrunch...................• Newburn<br />• DBench...........................• Netperf<br />• FTPload..........................• NIC Bonding<br />• File System Stress.........• Process Stress<br />• LMbench .......................• Sched Stress<br />• LTP.................................• Reaim<br />• Memeater......................• Tiobench<br />• Memtester<br /><br />Test otomasyonu için <a href="http://sourceforge.net/projects/hamsta">HAMSTA</a> 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.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-7320005.post-20263659782610918902008-04-05T10:12:00.000+03:002008-04-05T10:14:50.645+03:00Pardus Test Süreci'nin Dünü, Bugünü, Yarını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.<br /><br />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.<br /><br />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.<br /><br />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.<br /><br />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.<br /><br />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.<br /><br />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.<br /><br />Birinci Bölüm "Sürüm Öncesi Test Süreci"<br /><br />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.<br /><br />İkinci Bölüm "Düzenli Testler"<br /><br />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".<br /><br />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.<br /><br />Ayrıca her güncelleme sonrasında kararlı depodan güncellediğimiz düzenli güncellenen bir sanal imaja da ihtiyaç vardır.<br /><br />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.<br /><br />İş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.<br /><br />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 ).<br /><br />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...Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-7320005.post-3195032444886170562007-12-11T16:04:00.000+02:002007-12-11T16:24:29.050+02:00Çarşı OOXML 'e KARŞI !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;<br /><br />Sayın Yetkili,<br /><br />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.<br /><br />1- Cenevre'deki Ballot Çözüm Toplantısı'nda (DIS 29500) TSE'yi kim temsil edecek?<br /><br />2- Toplantıya ülkemiz adına katılacak olan delegeler, Microsoft'tan yeterince bağımsız mı?<br /><br />3- TSE'nin sorumlu komitesi 3500 çözüm önerisi veya hepsi değilse bile sadece gönderdikleri ulusal açıklamalar üzerinde çalışıyor mu?<br /><br />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 )<br /><br />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 ?<br /><br />a- Microsoft'un sunduğu belgede OOXML sistemi içersinde yer alan bir çok<br />maddenin sadece "isimleri" belirtilmiş ama bu maddeler tanımlanmamıştır.<br />Microsoft bu bilgeleri kendine saklamakta ve kesin bir tanım vermeyi<br />reddetmektedir.<br /><br />b- Bir başka durum ise Microsoft'un gönderme yaptığı standartları açık olarak<br />bildirmemesi. Örneğin bir karakter kümesinin birden fazla sürümü olduğu<br />durumda Microsoft bu karakter kümesinin hangi sürümüne gönderme yaptığını<br />bildirmemiştir. Bu durumda A kişisi ürettiği bir belgeyi iki farklı<br />arkadaşına yolladığı zaman bu iki kişi aynı belgeyi sadece farklı editörler<br />kullandıkları için özgün halinden başka bir şekilde görebilirler.<br /><br />c-Microsoft OOXML standardında kullanacağını beyan ettiği bazı alt sistemleri<br />kendi patenti altında barındırmaktadır. Bu durumun en vahim sonucu Microsoft<br />patentlerinin kullanım hakkına sahip olmadan OOXML formatlı bir belgenin<br />açılmasının mümkün olmamasıdır. Microsoft bu belgede bu teliflerin kamunun<br />kullanımına açılıp açılmayacağı konusunda herhangi bir açıklamada<br />bulunmamıştır.<br /><br />d- Microsoft OOXML ile ne yazık ki plartform bağımsız bir standart yaratmaktan<br />çok uzakta bir noktadadır. Bu haliyle OOXML ancak Windows ortamında ve ancak<br />Office programı aracılığı ile tam ve verimli olarak kullanılabilecek gibi<br />görünmekte. Diğer editörler (örneğin OpenOffice) OOXML formatlı belgeleri ya<br />hiç açamayacak ya da açabilseler bile özgün belgenin görünüm ve içeriğinden<br />çok farklı ve sorunlu bir şekilde görüntüleme imkanı sunacaktır.Unknownnoreply@blogger.com7tag:blogger.com,1999:blog-7320005.post-65063310381117815002007-10-10T23:11:00.000+03:002007-10-10T23:17:32.765+03:00Mehmet<div align="center"><span style="font-family:Times New Roman;"><span style="font-size:100%;"><b>Olur ya, bir çatışmada ölürsem,</b></span></span><br /><span style="font-family:Times New Roman;"><span style="font-size:100%;"><b>Arkamdan yas tutmayın.<br /><br /></b></span></span> <span style="font-family:Times New Roman;"><span style="font-size:100%;"><b>Bırakın toprağımda rahat içinde yatayım.</b></span></span><br /><span style="font-family:Times New Roman;"><span style="font-size:100%;"><b>Bedenimden komandomu çıkarmayın,</b></span></span><br /><span style="font-family:Times New Roman;"><span style="font-size:100%;"><b>Onlar benim onurumdur,</b></span></span><br /><span style="font-family:Times New Roman;"><span style="font-size:100%;"><b>Ölünce kefenim olacak...<br /><br /></b></span></span> <span style="font-family:Times New Roman;"><span style="font-size:100%;"><b>Başımdan mavi beremi çıkarmayın,</b></span></span><br /><span style="font-family:Times New Roman;"><span style="font-size:100%;"><b>O benim şanım,şerefim olacak...<br /><br /></b></span></span> <span style="font-family:Times New Roman;"><span style="font-size:100%;"><b>Ayağımdan botlarımı çıkarmayın,</b></span></span><br /><span style="font-family:Times New Roman;"><span style="font-size:100%;"><b>Onlar nice yollar aşacak,</b></span></span><br /><span style="font-family:Times New Roman;"><span style="font-size:100%;"><b>Şehit olursam Sırat köprüsünden geçecek...<br /><br /></b></span></span> <span style="font-family:Times New Roman;"><span style="font-size:100%;"><b>Elimden tüfeğimi almayın,</b></span></span><br /><span style="font-family:Times New Roman;"><span style="font-size:100%;"><b>O benim mezarıma sembol olacak...<br /><br /></b></span></span> <span style="font-family:Times New Roman;"><span style="font-size:100%;"><b>Yaramın kanını silmeyin,</b></span></span><br /><span style="font-family:Times New Roman;"><span style="font-size:100%;"><b>Ahirette hesabı sorulacak...<br /><br /></b></span></span> <span style="font-family:Times New Roman;"><span style="font-size:100%;"><b>Göğsümden kör kurşunu çıkarmayın,</b></span></span><br /><span style="font-family:Times New Roman;"><b><span style="font-size:100%;">O benim madalyam olacak...</span></b> </span></div><br /><br />* <span style="font-size:100%;">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.</span>Unknownnoreply@blogger.com1tag:blogger.com,1999:blog-7320005.post-3848242715619081862007-10-09T01:34:00.000+03:002007-10-09T01:35:49.516+03:00Gençliğe Hitabe<div class="content"> <div class="post" id="post-14"> <div class="entry"> <p align="left"><span style="font-family:Matura MT Script Capitals;font-size:+2;"><strong><em>Ey Türk gençliği! Birinci vazifen, Türk istiklâlini, Türk cumhuriyetini, ilelebet, muhafaza ve müdafaa etmektir.</em></strong></span></p> <p align="left"><span style="font-size:+2;"><strong><em><span style="font-family:Matura MT Script Capitals;"><br /></span></em></strong></span></p><p align="left"><span style="font-size:+2;"><strong><em><span style="font-family:Matura MT Script Capitals;">Mevcudiyetinin ve istikbalinin yegâne temeli budur. Bu temel, senin, en kıymetli hazinendir. Istikbalde dahi, seni bu hazineden mahrum etmek</span></em></strong> <strong><em><span style="font-family:Matura MT Script Capitals;">isteyecek, dahilî ve haricî bedhahların olacaktır. Bir gün, İstiklâl ve cumhuriyeti müdafaa mecburiyetine düşersen, vazifeye atılmak için, içinde</span></em></strong> <strong><em><span style="font-family:Matura MT Script Capitals;">bulunacağın vaziyetln imkân ve şerâitini düşünmeyeceksin! Bu imkân ve şerâit, çok nâmüsait bir mahiyette tezahür edebilir. İstiklâl ve</span></em></strong> <strong><em><span style="font-family:Matura MT Script Capitals;">cumhuriyetine kastedecek düşmanlar, bütün dünyada emsali görülmemiş bir galibiyetin mümessili olabilirler. Cebren ve hile ile aziz vatanin,</span></em></strong> <strong><em><span style="font-family:Matura MT Script Capitals;">bütün kaleleri zaptedilmiş, bütün tersanelerine girilmiş, bütün ordulari dagitilmiş ve memleketin her köşesi bilfiil işgal edilmiş olabilir. Bütün</span></em></strong> <strong><em><span style="font-family:Matura MT Script Capitals;">bu şerâitten daha elîm ve daha vahim olmak üzere, memleketin dahilinde, iktidara sahip olanlar gaflet ve dalâlet ve hattâ hiyanet içinde</span></em></strong> <strong><em><span style="font-family:Matura MT Script Capitals;">bulunabilirler. Hattâ bu iktidar sahipleri şahsî menfaatlerini, müstevlilerin siyasi emelleriyle tevhit edebilirler. Millet, fakr ü zaruret içinde</span></em></strong> <strong><em><span style="font-family:Matura MT Script Capitals;">harap ve bîtap düşmüş olabilir.</span></em></strong></span></p> <p align="left"><span style="font-size:+2;"><strong><em><span style="font-family:Matura MT Script Capitals;"><br /></span></em></strong></span></p><p align="left"><span style="font-size:+2;"><strong><em><span style="font-family:Matura MT Script Capitals;">Ey Türk istikbalinin evlâdı! İşte, bu ahval ve şerâit içinde dahi, vazifen; Türk istiklâl ve cumhuriyetini kurtarmaktır! Muhtaç oldugun kudret,</span></em></strong> <strong><em><span style="font-family:Matura MT Script Capitals;">damarlarındaki asil kanda, mevcuttur!</span></em></strong></span><br /><span style="font-family:Matura MT Script Capitals;font-size:+3;"> </span></p> <p align="left"><span style="font-family:Matura MT Script Capitals;font-size:+3;"> K. ATATÜRK</span> <span style="font-family:Matura MT Script Capitals;font-size:+3;"> </span><br /><span style="font-family:Matura MT Script Capitals;"><span style="font-size:+3;"> </span><strong><em><span style="font-size:+2;">20 Ekim 1927</span></em></strong></span></p> </div> </div> </div>Unknownnoreply@blogger.com1tag:blogger.com,1999:blog-7320005.post-67667761796238836032007-10-07T02:00:00.000+03:002007-10-07T02:06:47.406+03:00Hayali Yazılımcı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 <a href="http://www.haberturk.com/haber.asp?id=39170&cat=210&dt=2007/10/06">buradan</a> okursunuz.<br /><br />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.Unknownnoreply@blogger.com2tag:blogger.com,1999:blog-7320005.post-82102270098024999062007-10-04T00:49:00.000+03:002007-10-04T00:59:11.200+03:00Bağlantısız Haber TelevizyonuOdatv.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.<br /><br />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.<br /><center><br /><object type="application/x-shockwave-flash" data="http://www.odatv.com/flvplayer.swf" height="274" width="320"><param name="movie" value="http://www.odatv.com/flvplayer.swf" /><param name="flashvars" value="file=http://www.odatv.com/player/playlist.php?videoid=346" /><param name="wmode" value="transparent" /></object></center>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-7320005.post-3039885045206770312007-09-30T11:51:00.000+03:002007-09-30T12:05:41.154+03:00Bir Başkadır Benim MemleketimKendimi dakika başı blog yaza asosyal bir adam gibi hissetmeye başladım ama bunları yazmazsam çatlarım ;)<br /><br />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 "<a href="http://www.sahibinden.com/displayitem.php?a=4387858">Türkiye Malezya Olur Mu ?</a>" :)<br /><br />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 <a href="http://www.haberturk.com/haber.asp?id=38251&cat=200&dt=2007/09/30">söylemeli</a> artık.<br /><br /><br />Not: Tabi habertürk ün röpörtajı %100 hayali de olabilir. Güzide basınımızdan beklenecek bir davranış.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-7320005.post-20616409596135380792007-09-29T14:02:00.000+03:002007-09-30T01:16:53.776+03:00Pek Leziz !<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh7Np94eCcf64XrBBQF08fnMe6Nlh4tBIS4rv1AbJIj16O9Qtz0DVZGHikdvfdgBYysjvVhvJaBp4n5btoyql1gWAoZRIh74zQ_xJZyM82IgSmmvUOt7mMYfXhKVrEEk5il-LVSmQ/s1600-h/Chateaubriand.jpg"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh7Np94eCcf64XrBBQF08fnMe6Nlh4tBIS4rv1AbJIj16O9Qtz0DVZGHikdvfdgBYysjvVhvJaBp4n5btoyql1gWAoZRIh74zQ_xJZyM82IgSmmvUOt7mMYfXhKVrEEk5il-LVSmQ/s320/Chateaubriand.jpg" border="0" alt=""id="BLOGGER_PHOTO_ID_5115753572131772914" /></a><br />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. <br /><br />Ö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.<br /><br /><br /><br />Yazının tamamı ilgili bağlantıda mevcut ancak ben size beğendiğim yerlerden birkaç dilim keseyim;<br /><br /><blockquote><br />Ü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. </blockquote><br /><blockquote>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.</blockquote><br /><br />Neyse efendim fazla vaktinizi almadan sizi bu lezzetli yazıyla başbaşa bırakayım.<br /><a href="http://www.aksam.com.tr/yazar.asp?a=93287,10,19"><br />[1]</a>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-7320005.post-49423590549808008022007-09-25T16:46:00.000+03:002007-09-25T16:52:28.600+03:00Shame on Me !Über müzik kültürüne sahip bir şahsiyet değilim. Ama yine de bu zamana kadar böyle bir sesi fark edememişim.<br /><br /><object width="425" height="350"><param name="movie" value="http://www.youtube.com/v/uoGdx3I3dPE"></param><param name="wmode" value="transparent"></param><embed src="http://www.youtube.com/v/uoGdx3I3dPE" type="application/x-shockwave-flash" wmode="transparent" width="425" height="350"></embed></object>Unknownnoreply@blogger.com1tag:blogger.com,1999:blog-7320005.post-8083532606153694502007-09-22T12:43:00.000+03:002007-09-22T14:04:12.961+03:00Beyaz ötesi gülüşler için FARE ZEHİRİ kullanın !Artık komplo teorisi olmaktan çıkmış bir idda. <a href="http://www.iyibilgi.com/haber.php?haber_id=34429">Türkçe</a> , <a href="http://www.fluoridealert.org/">İngilizce</a>. Beyaz gülüşler efenim.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-7320005.post-15412578784696821282007-08-27T09:48:00.000+03:002007-08-27T09:52:54.651+03:00Death Note- Death Note'a ismi yazılan insan ölür. İsmi yazıldıktan sonra 40 saniye sonra ölüm nedeni, ölüm nedeninden 6 dakika 40 saniye sonra detaylar yazılabilir.<br />- Death Note'u kullanan biri, öldüreceği insanın yüzünü görmüş olmalıdır. Aynı isimdeki diğer kişiler bu şekilde etkilenmezler.<br />- Death Note'u kullanan insan ne cennete ne cehenneme girebilir.<br />- Death Note başkalarına verilebilir. Ancak bu durumda onunla ilgili tüm hatıralar kişinin aklından silinir.<br />- Death Note olanaksız şeyleri sağlamaz.<br />- Shinigamilerin gözleri, insanların adı ve soyadını, yaşam süresini, yaşını vb. gösterir. İnsanlarla bu gözler değiştirilebilir ancak karşılığında insan ömrünün yarısı Shinigami'ye geçer.<br />- Bir Shinigami, insan hayatını kısaltmak için yaratılmıştır. Bunu uzatmak için defteri kullanan Shinigami ölür.<br />- Death Note, eğer bir insanın eline geçerse, deftere önceden sahip olan Shinigami, o kişiyi 39 gün içinde bulmalıdır. Bu kitap ölüm tanrısı ile insan arasında bir bağ olacaktır.<br /><br />Evet efendim yeni hastalığımız bu. Herkese tavsiye edilebilecek pek leziz bir anime. Bağımlılık yapması dışında hiçbir yan etkisi bulunmamaktadır.Unknownnoreply@blogger.com6