Cumartesi, Ekim 24, 2009

selenium qooxdoo eklentisini yamalamak lazım

qooxdoo bir kez daha ömrümü tüketti. selenium ile basit bir test yazayım dedim, bir düğmeye tıklayabilme mücadelesinde kayboldum gittim.

öncelikle qooxdoo uygulamanıza selenium testi yazabilmek için şu eklentiye ihtiyacınız var. yalnız bu eklentiyi çalıştırabilmeniz için eski bir firefox ve eski bir qooxdoo versiyonu kullanmanız gerekiyor.

uzun lafın kısası, debelenmelerimin sonucu şu yama ortaya çıktı, bu şekilde firefox 3 civarı ve qooxdoo-0.8.3 için çalışıyor.

ama testlerin, derlenmiş (./ generate build) qooxdoo uygulamasında çalışmıyor olması, ve selenium qooxdoo elemanlarını bulabilsin diye koda setUserData çağrıları eklemek gerekiyor olması insanı biraz soğutuyor açıkcası.

nedir bu qooxdoo'dan çektiğim benim.

evlendim ve işimi değiştirdim

son girdimden bu yana hayatımda bir takım önemli değişiklikler oldu, sonunda esra ile evlenmeyi başarabildik (borçlarını ödemeye devam ediyoruz gerçi) ve mynet'te işe başladım.

mynet'te 3. ayımı doldurdum, deneme süresi 2 ay olduğuna göre ya kovmayı unuttular ya da artık resmi olarak mynet çalışanıyım.

mynet'e geçiş hikayemi özetlemek gerekirse;

zeitin, çalışanların özveride bulunması gerektiği bir modele geçmek zorunda kaldı, evliliğim nedeniyle özveride bulunamayacak durumda olduğumdan, pek istemediğim bir zamanda gemiyi terketmek zorunda kaldım.

parkyeri'ne geri dönemedim, zeitin'deki insanların psikolojisini bozmak istemedim. bir de farklı dünyaları tanıma isteğim vardı, gözünü parkyeri'nde açmış ve parkyeri çatısı altında büyümüş bir insan olarak. intimatek'e de geçemedim, o zaman da mavcı'ya ayıp olacaktı.

iş ararken ya ağ mühendisliği ya da test mühendisliği diye yola çıktım, ancak benim istediğim maaş seviyesi icin tecrübeye bakıyordu insanlar haklı olarak, yine biraz evliliğimin zorlaması ile tecrübem dahilindeki işlere de başvurmaya başladım, ve kendimi mynet'te buldum. yaklaşık bir 4 aydır mynet çatısı altında adklik projesinde yazılım geliştirici olarak çalışıyorum.

mynet'in yanı sıra siberfiber projesine de devam etmeye çalışıyorum boş zamanlarımda, hobi olarak. siberfiber, parkyeri ortaklarından giray abi'nin kardeşleriyle birlikte kurduğu, başında selçuk abi'nin olduğu 'intimatek' şirketi bünyesinde başlatılmış ve tübitak desteği almış güzel bir proje, siberfiber'i 3 kelimeyle anlatabilmem mümkün değil, bu yüzden onun için ayrı bir girdi yapmayı düşünüyorum.

özetle zeitin altında yürüttüğümüz gökada ve vidi projelerinden koptum, hayata adklik ve siberfiber projeleriyle devam etmekteyim.

işte öyle.

Cumartesi, Temmuz 11, 2009

red5, rtmp ve flash ile ilgili öğrendiklerim

uzun zamandır bloğumu ihmal ettiğimi farkettim, ve işin ilginci son 5-6 aydır red5 ile yatıp red5 ile kalkan bir insan olarak nedense hiç red5 ile ilgili bir girdi yapmamışım. öğrendiklerimi tek bir girdide toplayıp acısını çıkarayım dedim.

öncelikle rtmp açık bir protokol değil, dolayısıyla red5 bir tersine mühendislik ürünü, facebook'un bile red5 tercih ettiğini düşünecek olursak oldukça da başarılı bir ürün. bu arada adobe 2009 yılının ortasında rtmp belirtimlerini açacağını duyurmuş olmasına rağmen henüz açmadı.

rtmp bağlantıları tcp soketleri üzerinden kuruluyor, neden udp değil anlamış değilim, tcp'nin kayıpsızlığı canlı video aktarımlarında biraz sıkıntı yaratıyor. yetersiz bağlantılarda gecikmeler kaçınılmaz hale geliyor. gelen yayına (stream) müdahale edemiyorsunuz, sadece izleyenlere giden yayında paket düşürebiliyorsunuz ki elinizi koda bulaştırmadan bu paket düşürme işlerini yapamıyorsunuz.

elinizi koda sokma sıkıntısı ölçeklendirme ve red5'den red5'e yayın aktarma konusunda da var. ölçeklendirme için terracotta kullanıyor insanlar[1], sunucudan sunucuya yayın aktarma işi için de örnek kod bulmak mümkün değil, teoride nasıl yapılabileceğini e-posta listesinde bulmak mümkün[2], yani kolları biraz sıvamak şart bu işlere girmeniz gerekirse.

red5 ön tanımlı olarak, 5080'den http, 1935'den rtmp, 8443'den rtmps ve 8088'den rtmpt sunuyor. bu durumda şirketlerin güvenlik duvarlarına takılıyorsunuz doğal olarak. çoğu yerde sadece 80 portuna izin veriliyor. biz vidi için red5 üzerinden axis ile hem bir webservisi sunuyoruz hem de rtmp hizmeti sunuyoruz. yani en az 2 port açmamız gerekiyordu aynı sunucu üzerinde. bu engeli de vidi uygulamasının web.xml'inde bazı servlet ayarları yaparak aştık[3].

rtmpt aslında http'den başka bir şey değil. yayın verileri peşpeşe http paketleri olarak aktarılıyor. dolayısıyla aynı port üzerinden hem webservisini hem rtmpt sunmak için şu servlet ayarlarını eklemeniz yeterli:


<servlet>
<servlet-name>rtmpt</servlet>
<servlet-class>org.red5.server.net.rtmpt.RTMPTServlet</servlet>
<load-on-startup>1</load>
</servlet>

<servlet-mapping>
<servlet-name>rtmpt</servlet>
<url-pattern>/fcs/*</url>
</servlet-mapping>

<servlet-mapping>
<servlet-name>rtmpt</servlet>
<url-pattern>/open/*</url>
</servlet-mapping>

<servlet-mapping>
<servlet-name>rtmpt</servlet>
<url-pattern>/close/*</url>
</servlet-mapping>

<servlet-mapping>
<servlet-name>rtmpt</servlet>
<url-pattern>/send/*</url>
</servlet-mapping>

<servlet-mapping>
<servlet-name>rtmpt</servlet>
<url-pattern>/idle/*</url>
</servlet-mapping>


iletişimi ssl ile şifrelemek için yaptığımız çalışmalarda da anladık ki aslında rtmps diye bir şey yok, rtmps=rtmpts=https demek mümkün. ssl işinde baya zorlandık, 0.7.4'de çalışmayınca 0.8 sürümlerine geçtik, orada da çalışmadı, bir düzine deneme sonrası sadece 0.8-RC2 versiyonunda çalıştırmayı başarabildik. bu versiyonun üstünde de altında da problemler yaşadık.

flash player tarafında ise, uygulama tasarımına girişmeden flash kısıtlarını araştırmak da fayda var. örneğin flash'ın izin kutucuklarının boyutu sabit, bu boyutun altında bir flash yaratırsanız kullanıcı kamerayı kullanma iznini veremiyor, ve eğer kullanıcı hatırla kutucuğunu işaretlememişse her flash için bu izni ayrı ayrı vermesi gerekiyor. eğer ekranda flashın tamamı gözükmüyorsa flash üzerindeki herhangi bir düğmeye tıklayamıyorsunuz. tam ekran yapma gibi işlevleri kullanıcı bir yere tıklamadıkça yapamıyorsunuz. bir de flash'i içine entegre ettiğiniz siteden başka bir alan adından sunacaksanız atmanız gereken epey bir takla var, flash'ın güvenlik politikası ile ilgili belgeleri bir okuyun derim ben. böyle ufak detaylar uygulama tasarımını tamamen değiştirebiliyor.

sunucuyla flash istemciler arasındaki komut iletişimi için shared object yerine uzak fonksiyon çağrılarını kullanmakta fayda var, red5'in shared object gerçeklemesinde sıkıntılar var.

bunun dışında geliştirme ortamı olarak linux üzerinde çalışan insanlar olarak actionscript yazmak da çok zorlanmadık, flex3sdk ve derlemeler için ant kullanımı yeterli oldu. ama ince çizimler yapacağım, tasarımla uğraşacağım diyorsanız linux çok doğru bir tercih değil.

red5'i kapalı devre sistemler için kullanıp kullanamacağımızı görmek için kalite konusunda sınırıları zorlama durumunda da kaldık, gördük ki flash player ile dvd kalitesine (480 satır) kadar çıkmak mümkün. dvd normalde 7-8 mbit/s'lik bir bant genişliği gerektiriyor, red5'de ise bant genişliği kontrollerini aktif hale getirmeden 1mbit/s'lik upload hızını aşamıyorsunuz, bant genişliği kontrollerini aktif hale getirebilmek için de biraz kod yazmanız gerekiyor.

yalnız 480 satırdan sonra flash oynatıcı çatlamaya başlıyordu. bir de flash oynatıcı ile görüntüyü sadece h.263 veya vp6 kodlayabiliyorsunuz. flash oynatıcı h.264 kodlayamıyor ama oynatırken h.264'u çözebiliyor. veri miktarını azaltmak için h.264 kullanmak elzem. bu arada xuggler[4] ile gelen yayını dağıtmadan kodlamasını değiştirmek mümkün. ama biz gönderirken h.264 gönderelim dedik flash oynatıcı dışında neyle yayın gönderebiliriz diye araştırdık. rtmp'nin belirtimlerinin kapalı olmasından olsa gerek pek bir alternatif yoktu. yaptığımız araştırmalarda rtsp'nin çok yaygın kullanıldığını gördük. eğer rtmp yayınını rtsp'ye dönüştüren bir ara uygulama olsa baya artacak alternatif sayısı aslında.

vlc 0.9 sonrasında rtmp izleme desteği geliyordu, ama sunucuya görüntü gönderilemiyordu. bu arada vlc'nin red5 ile çalışması için vlc kodunda bazı kontrolleri kaldırıp yeniden derlememiz gerekti. vlc ile flash oynatıcıdan çok daha başarılı bir görüntü akışı elde ettik, ama çok daha fazla gecikme gibi bir bedeli vardı. gecikmenin tam nedenini anlayacak kadar bakamadık henüz. görüntü aktarımı için java'yla yazılmış bir kod bulduk, ama yeterince olgun olmadığını düşündüğümüz için tercih etmedik. sonunda adobe flash media encoder kullanmak durumunda kaldık, bu da windows bağımlılığı anlamına geldiğinden hiç istemediğimiz bir durumdu. bu arada adobe flash media encoder ile red5'e rtmpt üzerinden yayın aktarmak için red5'te "content type" ile ilgili bir kontrolü kaldırıp yeniden derlememiz gerekti.

kalite denilince kodlamadan ziyade görüntüyü taşıdığınız arabirimler önem kazanıyor. red5'e görüntü aktarmak için bilgisayarınızın görüntü kaynağını webcam olarak algılaması gerekiyor. eğer bir yakalayıcı (capture) kart kullanırsanız televizyona verebildiğiniz herhangi bir görüntüyü (bir televizyon kanalını, bilgisayar ekranı görüntüsünü, veya composite çıkışı olan herhangi bir kamerayı, dvr kameraları) kullanabilirsiniz. burada veriyi sayısal olarak taşımak önemli (hdmi, dvi). anolog olarak ise sadece component arabirimi hd kalitesine (1080 satıra) izin veriyor. yalnız yakalayıcı kartlarda yüksek çözünürlük, sayısal arabirim dediğinizde fiyatlar biraz uçuyor.

şimdilik aklıma gelenler bu kadar, sonradan birşeyler hatırladıkça bu girdiye eklemeyi düşünüyorum. bir de yukarıda üstün körü geçtiğim yerlerden açılmasını istediğiniz varsa yorum bırakırsanız gerekli ekleri yapabilirim.

[1] http://www.terracotta.org/confluence/display/wiki/Red5+and+Terracotta+POC
[2] http://osflash.org/pipermail/red5_osflash.org/2007-December/017650.html
[3] http://gregoire.org/2009/01/28/rtmpt-and-red5/
[4] http://www.xuggle.com/xuggler/

Pazar, Nisan 26, 2009

flowplayer bwcheck eklentisi için red5 örneği

şuradaki rtmp örneğini red5 üzerinde çalıştırabilmek için tüm flowplayer'i anlamam gerekti, internette sadece yarım yamalak bilgiler bulabildim, yaşadığım süreci başkaları için hızlandırabilmek adına yaptığım ayarları paylaşayım dedim:

index.html:

<html>
<head>
<script type="text/javascript" src="flowplayer-min.js"></script>
</head>
<body>
<div id="info">click below to see most appropriate video to your bandwidth</div>
<a class="rtmp" id="red5"><img src="img/showme.png" /></a>
<script language="JavaScript">
$f("red5", "swf/flowplayer-3.1.0.swf", {
log: {
filter: 'org.flowplayer.bwcheck.*',
level: 'debug'
},

clip: {
url: 'skyandice.flv',
urlResolvers: 'bwcheck',
live: true,
provider: 'rtmp'
},

plugins: {

bwcheck: {
url: 'swf/flowplayer.bwcheck-3.1.0.swf',
netConnectionUrl: 'rtmp://red5ip:1935/bwcheck',
bitrates: [40, 150, 400, 700, 1000],
serverType: 'red5',
rememberBitrate: false,

onBwDone: function(url, chosenBitrate, bitrate) {
var el = document.getElementById("info");
el.innerHTML = "Your speed is: " +bitrate+ "<br />Video file served: " +url;
}
},

rtmp: {
url: 'swf/flowplayer.rtmp-3.1.0.swf',
netConnectionUrl: 'rtmp://red5ip:1935/oflaDemo'
}
}
});
</script>
</body>
</html>


kullanilan dosyalar:

http://static.flowplayer.org/img/player/btn/showme.png # img altina
http://static.flowplayer.org/video/skyandice-40.flv
http://static.flowplayer.org/video/skyandice-150.flv
http://static.flowplayer.org/video/skyandice-400.flv
http://static.flowplayer.org/video/skyandice-700.flv
http://static.flowplayer.org/video/skyandice-1000.flv
# skyandice*.flv'ler /usr/lib/red5/webapps/oflaDemo/streams altına (artık siz nereye kurduysanız)
http://flowplayer.org/releases/flowplayer.bwcheck/flowplayer.bwcheck-3.1.0.swf
http://flowplayer.org/releases/flowplayer.rtmp/flowplayer.rtmp-3.1.0.swf
http://flowplayer.org/releases/flowplayer/flowplayer-3.1.0.zip
# flowplayer-3.1.0.swf, flowplayer.controls-3.1.0.swf, flowplayer-3.1.0.min.js de bu zip dosyasından geliyor
# tum swfler swf dizini altına


bir de http://red5ip:5080/installer adresinden bwcheck ve oflaDemo uygulamalarını kurmuş olmanız gerekiyor.

umarım birilerine faydası dokunur.

Pazar, Nisan 19, 2009

anarşik bir iş ortamında iş yapabilmek

zeitin'de demokrasinin de ötesinde anarşik bir düzen daha doğrusu düzensizlik hüküm sürüyor şu sıralar, anarşinin son bulduğu tek nokta ise öncelik listemiz, parkyeri'ndeyken bölüm sorumluları ve şirket ortakların bir araya geldiği eşgüdüm toplantılarında her bölüm için o haftanın öncelikli işlerini çıkarmaya çalışırdık. zeitin'de sayımız az olduğundan, herkesin katıldığı haftalık şirket toplantıları yapmaya başlamış ve eşgüdüm işini de bu toplantılarda halletmeye çalışmıştık, ancak anerşik yapımız bu toplantıların devamlılığını getirmemize engel oldu, ve muhtemelen küçük bir şirket için en uygun olan yönteme kendiliğinden bir yönelim yaşadık, işlerin önceliklendirilmesi işini bir kişi kendi başına yapar duruma geldi, şu anda da bu işi giray abi üstlenmiş durumda.

bu hafta, önceliklerimizin dışında bir işle uğraşınca alper'den tepki aldım. anarşinin getirdiği yan etkilerden biri de bu, kimden ne zaman nasıl bir tepki alacağınızı tahmin etmek çok kolay değil. sonradan öğrendim ki alper de aynı işe talipmiş ve giray abilerle konuştuğunda işin önceliği engeline takılmış.

hiyerarşik bir düzende veya kuralların belli olduğu bir yerde herhangi bir hareketinizin sonuçlarını tahmin etmek biraz daha kolaydır, en azından mutlu etmeniz gereken insanlar bellidir. anarşik bir toplumda ise herkesin mutlu olmasını sağlamanız gerekiyor, bu da fazla ideal bir durum, pratikte çok mümkün gözükmüyor. dolayısıyla ortamda şikayetler eksik olmuyor, her an illa biri birilerinden veya bir durumdan şikayetçi, ve şikayetleri yönetmediğimizden, ilginiz olsa da olmasa da, ister istemez her şikayetten etkileniyorsanız. "ilginiz olsa da olmasa da" sözü aslında zeitin için çok yanlış, çünkü zeitin çalışanı iseniz her işle doğal olarak ilgili olduğunuzu kabul etmişsiniz demektir.

bugün zeitin'de sahip olduğumuz özgürlüklerin dünya üzerinde hiç bir şirket çalışanına sunulduğunu sanmıyorum, buna google da dahil. insanlar parkyeri'nin ve zeitin'in google'dan esinlendiğini düşünüyor, eğer benzetileceksek google'dan çok "SUN"'a benzetilmemiz bence daha doğru, benim uzaktan algıladığım "SUN" çok daha okul gibi tasarlanmış ve çalışan insiyatifinin ön planda tutulduğu bir şirket. google ise daha çok "mış gibi" yapan bir şirket. "don't do evil" diyip, android telefonlarda google hesabını zorunlu kılan, dağıtım gücünü tekel oluşturmak için kullanan bir şirket. "çalışanlarımıza zamanlarının %20'sinde istedikleri işi yapma özürlüğü tanıyoruz" diye reklam yapan, ama bu %20'de yapacağınız işi müdürünüze onaylatmanız gerektiği detayını pek paylaşmayan, içeride müdür gibi kavramların hüküm sürdüğü bir şirket. chrome ve chromium diye biri açık biri kapalı kaynaklı iki ayrı proje açıp tek taraflı faydaya dayalı bir camia gücü oluşturma peşine düşmüş bir şirket. bu gibi hareketler google'in samimiyetinden şüphe ettiriyor insanı.

zeitin olarak debian tercih etmemizin sebebi de bu, gerçekten özgürlüğü varoluş sebebi olarak koruyabilmiş tek dağıtım, genelde diğer dağıtımlar camia gücünü kullanmaya çalışan, başka amaçlarla yola çıkmış, çıktıkları yol özgür yazılımlarla kesiştiği için özgür yazılıma destek olan, pek çok konuda google'un yaptığı gibi "mış gibi" yapan dağıtımlar.

zeitin'in kurucularını tanıyan ve zeitin'in kuruluşuna şahit olma şansı yakalamış bir insan olarak, zeitin'in çalışan mutluluğu ve özgürlüğü üzerine kurulmuş bir şirket olduğuna, bu iki unsurun herşeyin önünde tutulmuş olduğuna birinci elden tanığım. umarım hep böyle kalabilir.

yalnız "özgürlük eşittir mutluluk" demek doğru değil, özgürlüğü başarılı olma sebebi olarak göstermek de doğru değil. ama hem özgür hem başarılı olunabilir.

herkesin özgür olması demek anarşi demek, anarşilerde huzursuzluk oluşması doğal, bu huzursuzluklara çözüm demokrasi olabilir, yalnız demokrasiyi zeitin'e çok uyarlayamıyoruz çünkü demokrasi beraberinde yasaları getiriyor, yasa demek yasak demek. (gerçi başbakanımız en son türban mevzularında "artık yasaklar ülkesi olmayalım" gibi ilginç demeçlerde bulunmuştu, ya başbakanın bir yanlışı var ya benim, bildiğim kadarıyla yasaklarla yönetilmeyen herhangi bir ülke yok, tek yaptığımız ülkeleri yasakları koyuş ve uygulayış şekline göre sınıflandırmak)

yasa ve yasakların ters tarafı zamanla hiç duymadığın bilmediğin kurallara tabi hale gelmen. bunu çözüm de yasaları yazmayıp töreler gibi yazılı olmayan kurallarla ilerlemek, uygulama konusunda da toplumsal yaptırımlara başvurmak, yani mahalle baskısına izin vermek. bu durumda "bir yasayı duymadıysan o yasa yoktur" kuralı işler.

bu son örnekte, önceliklerimizin dışına çıkarak törelerimize karşı gelmiş oldum sanırım, karşıma da ilk çıkan alper oldu, beni destekleyen kimse çıkmadığından mahalle baskısını da yemiş oldum. ancak herşeye rağmen başladığım işi bitirmekte ısrar ettim, "ya bu işi yaparım, ya da işime son verirsiniz" diye çıkışınca engelleri aşmış oldum, muhtemelen ay sonunda başarım değerlendirmemin olumsuz etkilenmesi gibi son bir yaptırım daha yiyeceğim, bir daha böyle bir şey yapmamam için (şu an başarım değerlendirmesi işini de giray abi üstlenmiş durumda, bu cezayı verip vermeme kararını verecek insan da kendisi dolayısıyla)

yapacağım iş sürüm çıkma yöntemimizi değiştirecekti, parkyeri zamanlarından beri sürümlerin deb paketi olarak çıkılmasını, sürümlerimizi ve bağımlılıklarını koyabileceğimiz bir debian depomuz olması gerektiğini savunan bir insan olarak, yeni şirkette daha insanlar alışkanlıklarını oluşturmadan bu işin halledilmesi gerektiğini düşünüyordum, bu yüzden benim için oldukça öncelikli bir işti. giray abi işin önceliği konusunda benimle aynı fikirde değildi, ancak giray abinin öncelikleriyle ilerleyecek olsam muhtemelen 6 yıl beklemem gerekecekti (parkyeri'nin 6 yıldır debian kullanan ama debian deposu olmayan bir şirket olduğunu düşünecek olursak).

bu çok kritik bir işti, çünkü anarşik bir toplumda doğru zamanda doğru yerde yazacağınız ufak bir betik, bir araç ya da belirleyeceğiniz bir çalışma yöntemi, yeni bir "töre"'nin doğmasını tetikleyecektir. bu ilk bakışta zor koşma gibi bir yöntem gibi gözükse de aslında pek değil, çünkü eğer insanları saçma bir yönteme zorlarsanız kabullenmeyeceklerdir, direnç göstereceklerdir. tabi bunun çalışması için de akıllı ve sorgulayan insanlarla çalışmak gibi bir ön koşul gerekiyor. yalnız yöntem belirlemek yeterli değil, arkasında durmak da gerekiyor töreleştirebilmek için. bir süre sürüm işleriyle kendim ilgileneceğim, belirlediğim yöntemleri insanlara göstereceğim, eleştirlerini alacağım, yöntemlerin iyice olgunlaşması ve başkalarının da aynı yöntemleri kullanmasını sağlamak için mücadele edeceğim. zaten doğru bir şey yapıyorsam insanlar kısa zamanda benimseyecektir.

zeitin yeni bir şirket olduğundan, henüz insanlar sürüm hazırlama konusunda bazı alışkanlıklar oturtmamış olduğu için işim biraz daha kolay olacak. eğer zaman geçmesine izin verseydim sadece mantıklı bir yöntem önermem yetmeyecekti, aynı zamanda insanların eski alışkanlıklarını kırmak için çok zorlu bir mücadeleye girişmem gerekecekti ve muhtemelen başaramayacaktım.

bir diğer yöntem ise, işe girişmeden önce herkesi ikna etmek olabilirdi. bence bu yöntem çok masraflı, toplantı gibi ön koşullar gerektiriyor, toplantılarda herkezden bir anda yaptıkları işlerden uzaklaşıp sizin yaptığınız işe sizin kadar odaklanmalarını bekliyorsunuz, ben bunu gerçekten başarabilene şahit olmadım açıkcası. bir de bu yöntemde fikri öneren ile uygulayan farklı insanlar oluyor genelde, dolayısıyla önerilerin yeterince olgunlaşmaması gibi bir risk taşıyor.

eğer anarşik bir toplumda iş yapacaksanız, öncelikle yaptığınız işe inanmanız gerekiyor, motivasyonunuzu iyi belirlemeniz ve sağlam temellere oturtmanız gerekiyor, çünkü insanların tepkilerinin motivasyonunuzu kırmasına izin vermemelisiniz, başladığınız işi bitirmek gibi bir prensip edinmiş olmanız da işinize yarayacaktır.

insanların motivasyonunuzu kırmasına izin vermemeniz gerektiği gibi kendiniz de başkasının motivasyonunu gereksiz bozacak laflar etmemeniz gerekiyor. amacı olmayan cümlelerden uzak durmalısınız, ama amaçlı cümlelerinizi de sakınmamanız gerekiyor, yoksa şirket istemediğiniz bir yöne doğru kayabilir, desteklediğiniz töreleri yıpratıcı hareketlerden kaçınmanız önemli (gerçi alper'le yaşadığımız son örnekte buna uyamadım, çünkü yaptığım hareketin getirisi götürüsünden çoktu), bir de birinin hata yaptığını düşünüyorsanız mutlaka yüzüne karşı söylemeniz lazım, kendini düzeltme şansı tanımak için, ancak bunu yaparken kendinizin de hatalı düşünüyor olma ihtimalini göz önünde bulundurmanız şart. bu lafına dikkat etme meselesi o kadar da kolay değil, kurduğum cümlelerde kendime bir nebze hakim olabilsem de biri ters bir laf ettiğinde karşı saldırıya geçme gibi yenemediğim bir refleksim var, bu anlarda biraz şevk kırıcı olabiliyorum sanırım.

açıkcası zeitin'de çok huzursuz olduğum anlar olmadı değil, kafam rahat olsun da özgür olmayım dediğim anlar da oldu. ancak dönüp baktığımda görüyorum ki 3 ayda vidi gibi bir ürün çıkarabilmişiz ki aynı ölçeklerde kurumsal bir şirkete parasıyla aynı işi yaptırmaya kalksanız muhtemelen 1 sene de çıkacak bir ürün, 1 sene iyimser bir tahmin bile olabilir. daha duyurusunu yapmamış olduğumuz ve çok ses getireceğine inandığımız gokada adlı projemizde de yolu yarılamış durumdayız, şu anda bu proje kapsamında geliştirdiğimiz "thinclient" çözümünü şirket içerisinde kullanmaktayız.

yani görünen o ki anarşiyle, törelerle bir şekilde bir şeyler ortaya çıkarabiliyoruz, bir yazılımcı olarak bu başarı hissi, "bir şey ürettim" hissi çok önemli. umarım yakın zamanda ürünlerimizin satışını da başarabilir ve şirketimizin devamlılığını sağlayabiliriz.

Pazar, Mart 22, 2009

vim'le log renklendirme

logları "tail -f LOGDOSYASI | ccze -A" komudu ile takip etmeye alışmış insanlar olarak, sonradan logu bir editörle açtığımızdaki renksizlik epey gözlerimizi rahatsız ediyordu. bekir, sağolsun, vim için bir renklendirici yazdı, rahatladık. şuradan indirdiğiniz dosyayı ~/.vim/syntax dizinine koyup (eğer dizin yoksa, yaratın), bir log dosyasını vim ile açıp, ":set syntax=log" derseniz dünyanız renklenecektir. eğer her defasında ":set syntax=log" demek istemiyorsanız ~/.vimrc dosyanıza "au! BufRead,BufNewFile *log set filetype=log" satırını eklemeniz yeterli. özetle şudur:


#!/bin/sh
mkdir -p ~/.vim/syntax
cd ~/.vim/syntax
wget --no-check-certificate https://svn.bdgn.net/public/test/bekir/.vim/syntax/log.vim
echo "au! BufRead,BufNewFile *log set filetype=log" >> ~/.vimrc

Cumartesi, Mart 07, 2009

neden git kullanır insan?

şirkette subversion'dan git'e geçilmesi ardından yaşanan yoğun git karşıtlığı nedeniyle bir süredir git'i savunmak durumunda kalıyorum zaman zaman, ama çok da başarılı olduğum söylenemez, ben de savunmamı yazılı hale getirmeye karar verdim, belki böyle daha ikna edici olabilirim.

aslında şurada git'in diğer versiyon kontrol sistemlerine göre üstünlükleri oldukça detaylı açıklanmış.

kişisel tercih sebeplerimi özetlemem gerekirse:

* geliştirmenin bir kısmını teslim etmeye izin vermesi.
* 'git add -p' komuduyla çalıştırılan etkileşimli teslim modu.
* dallarla çalışmayı olağan hale getirmesi.
* geçmiş teslimleri birleştirme/bölme, teslim mesajını sonradan düzenleme gibi geçmişe yönelik işlemlere izin vermesi.
* ana depo ile klonlanan depo arasında bir farkın olmaması, daha doğrusu bir ana depo olmaması.
* başkasının yerine teslim edebilme olanağı sunması.
* "git-am" ile teslimlerin eposta yoluyla paylaşımının kolaylaştırılması.

bekir zamanında parkyeri'nde rcs'den svn'e geçildiğinde, insanların "nasıl yani, bir dosya değiştiğinde tüm deponun revizyonu mu değişecek" şeklinde tepki gösterdiklerinden bahsetmişti. git'e geçerek dosya dosya teslim edebilme özelliğimizi geri kazanmış olduk, hatta daha da fazlasını yapabilir hale geldik, artık hunk hunk teslimler yapabiliyoruz. yani değil dosya dosya, dosyada yaptığımız değişikliklerin bir kısmını bile teslim edebilir hale geldik.

git'te 3 aşamalı bir teslim anlayışı var. "git add" ile yaptığınız değişiklikleri önce "index"'e teslim ediyorsunuz; sonra "git commit" ile çalıştığınız dala; en son olarak da başka bir ana depo söz konusu ise "git push" ile, başka bir ana dal söz konusu ise "git merge" ile son teslimi yapmış oluyorsunuz.

svn'de "svn commit" ile tek aşamada yapılan bir işi niye böyle zorlu bir hale getirdik diye deliren insanlar olabiliyor bu durumda. öncelikle bu 3 aşamada yapılan işi, "svn commit"'in yaptığı işe denk saymak çok yanlış. geçmişte uzun zamanlı bir geliştirme yapacaksam (örneğin 1 haftalık) svn-rcs karışık kullanımına yöneliyordum. svn'den çektiğim depoyu aynı zamanda bir rcs deposuna çevirerek geri almayacağımdan emin olduğum değişiklikleri rcs deposuna teslim ediyordum, ve rcs diffleri üzerinden geliştirmeye devam ediyordum. aksi takdirde yama 1 haftada çok büyüyordu ve gözden geçirme olanaksız hale geliyordu. tabi svn-rcs karışık kullanımı bu derdimi çözüyor olmasına karşın hayatıma yeni dertler sokabiliyordu. git bu açıdan ilaç gibi geldi diyebilirim, bence gayet şık çözmüşler meseleyi. artık geliştirme esnasında ne zaman kopuk ve sonucundan emin olmadığım bir yola yönelecek olsam, "git add" ile kaybetmek istemediğim değişiklikleri öncelikle index'e alıyorum, koda korkmadan dalabiliyorum, baktım yolun sonu iyi değil, "git co ." ile anında temiz noktaya geri dönüş yapabiliyorum. 3 günlük bir geliştirme yapacaksam, her gün akşam "git add" ile yaptığım işi gözden geçirip varsa kalıcı kod, teslimlerimi yapıyorum, böylece 3 gün sonunda kocaman bir yama gözden geçirmektense bu işi gün gün yaparak gözden kaçırma durumunu en aza indirgemiş oluyorum.

"git add -p" index teslimlerini etkileşimli bir hale getirerek insanın işini epey bir kolaylaştırıyor. hunkları teker teker önünüze getirerek kabul edip etmediğinizi soruyor. tüm hunkların üzerinden geçerek kalacak kodları "index"'e ekliyorum, düzeltme gereken yerlerde arka planda değişiklikleri yapıyorum, hunklar bittikten sonra yeni düzeltmelerin teslimi için işlemi tekrarlıyorum, en sonunda sadece atılacak değişiklikler geriye kalıyor, "git co ." komuduyla bu kodları atıyorum.

svn-rcs karışık kullanacağına svn'de bir dal açsaydın da rahat etseydin diye düşünebilirsiniz, onu da denedim ancak svn'de dal kullanımı hiç de dökumanlarda yazıldığı gibi pratik bir şey değil. herşeyden önce dalı açma sebebim trunk'da yapamayacağım işleri dalda yapabilmek. peki bir insan trunk'da ne yapamaz? sonradan silme ihtimali olduğu kodların teslimini yapmaktan çekinir mesela, ya da tek satırlık teslimlerle ilerlemeyi tercih etmezsin genelde teslim logunu kirletmemek için. dalda bütün bunları yapabiliyorum artık güzel, geliştirmemizi bitirdik, geldik yaptıklarımızı trunk'a geçirmeye. bu aşamada benim yaptığım, dalı açtığım noktayla geldiğim son nokta arasındaki farktan hazırladığım yamayı trunk'a uygulamaktı. böylece dalda yazdığım çöp kodları ve tek satırlık teslimleri trunk'a almamış oluyordum, ancak o zaman da dal ile trunk arasındaki bağ kopuyordu, "svn merge" komudunu hiç kullanmaz oluyordum yani gerçek anlamda dal açmış olmuyordum aslında. svn'de dal açmış olmamın svn-rsc karışık kullanımına göre yarattığı tek fark geliştirmede geldiğim son noktayı ve geçtiğim aşamaları diğer insanlarla da paylaşabiliyor olmamdı. aslında "svn merge" hiç kullanmıyor da değildim, trunk'da yapılan değişiklikleri dala almak için tek yönlü bir şekilde kullanıyordum, onda da her defasında "svn merge -rX:Y" dediğimde X dahil oluyor muydu olmuyor muydu diye sürüncemede kaldığımı hatırlarım. dalda yaptığım değişikliklerden hazırladığım yamayı trunk'a uygulayıp teslim ettikten sonra, dalı trunk'la eşit hale getirme meselesi var tabi bir de. onun için de dalda, çatalladığım ilk revizyona döndükten sonra, o revizyon ile trunk'taki son revizyon arasını, geri aldığım dala "svn merge" ile birleştirirdim. bütün bu işlemler çok külfetli geldiğinden kısa sürede svn'de dal kullanımından vazgeçmiş, svn-rcs karışık kullanımına geri dönmüştüm.

peki svn'de dalla çalışmak problem de git de değil mi? pek değil, git'in tüm kurgusu dalların birleştirilmesi üzerine kurulu olduğundan tüm dal işlemleri gündelik hale geliyor, kısa sürede svn'de uzak durmaya çalıştığınız bir sürü şeyi çoktan refleks haline getirmiş oluyorsunuz. bir de git'te, "git rebase" diye bir komut var, yukarıda saydığım tüm problemleri tek kalemde çözüyor. bir daldan çatallayarak yeni bir dal oluşturdunuz, bu sırada ana dalda insanlar değişiklik yapmaya devam ediyor, bu değişiklikleri açtığıniz dala almak için "git rebase ANADAL" demeniz yeterli. ve artık açtığınız dalda korkmadan dilediğinizi özgürce yapabilirsiniz, çünkü git ile geçmişi de değiştirmeniz mümkün, yaptığınız tek satırlık teslimleri birleştirerek tek bir teslim haline getirebilirsiniz, geçmiş teslim mesajını değiştirebilir, "git cherry-pick" komudu ile başka dallarda hoşunuza giden değişiklikleri nokta atışı ile kendi dalınıza geçirebilirsiniz.

svn'de geçmişte değişiklik yapabilmeniz için svnadmin gibi bir komuda ve bazı izinlere ihtiyacınız olur, git'te ise bir depoyu klonladığınızda ana depoyu yerelinize çekmiş olursunuz. ana depo üzerinde yapabileceğiniz her işi yerelinizde de yapabilirsiniz. deponun geçmişinde bir şey değiştirebilmeniz için sistem yöneticilerine "şu değişikliği yapabilir misiniz?" diye e-posta atmanız gerekmez.

parkyeri'nde gözden geçirmeleri eposta ile yapardık, geliştirmenizi tamamladığınızda "[YAMA]" etiketli bir epostayla yamanızı yayınlardınız, herhangi biri gözden geçirip teslim edebilirsin dedikten sonra yamayı gönderen teslimi gerçekleştirirdi, eğer biri birşeyi beğenmezse yamayı gönderen gerekli değişiklikleri yapar ve tekrar bir yama gönderirdi. eğer süreç şu şekilde olsa bence daha etkin bir çalışma yöntemi olurdu. geliştirmesini bitiren yamayı yayınlar, bir diğer kişi yamayı kendi deposuna uygular, problemli bulduğu yerlerde istediği değişiklikleri yapar ve teslimi gerçekleştirir. bu şekilde aynı yamanın ufak değişiklikler yüzünden 8 defa gönderilmesi derdinden de kurtulmuş oluyoruz. bir de yama gözden geçirmek için eposta üzerinden hızlıca bir göz atmak çok uygun bir yöntem değil, gözden kaçırmalara çok açık, yamayı yerelinize uygularsanız ister istemez testini de yapar halde bulacaksınız kendinizi, bu da gözle yakalayamadığınız hataları yakalayabilmenizi sağlayacaktır, örneğin yamaya eklenmesi unutulmuş bir değişiklik varsa, veya ayar dosyasında yapılması gereken bir değişiklik yamaya eklenmemişse testiniz patlayacağından anında durumun farkına varabilirsiniz.

yalnız bu çalışma yönteminde, svn'de başkasının yerine teslim yapamadığınızdan değişikliklerin sahiplik bilgisinin kaybedilmesi gibi ciddi bir dert var. git'te ise istediğiniz kişi bilgileriyle teslim yapmanız mümkün. ve özellikle "git am" komudu ile teslimlerin eposta ile paylaşımı çok pratik bir hal aliyor, tek bir komutla eposta'daki yamayı yerelinize teslim edebiliyor ve yerelinizdeki teslimleri eposta haline getirebiliyorsunuz.

sonuç olarak bence git üzerine gerçekten kafa yorulmuş ve güzel tasarlanmış, kişisel olarak yasadığım bir çok derde çözüm oldu. git diğer versiyon kontrol sistemlerinin sunduğu özellikleri sağladığı gibi daha da fazlasını sunuyor. o yüzden git kullanan bir insan herhangi bir versiyon kontrol sistemini kullanabilir, ama tersinin doğru olduğunu söylemek zor. bu nedenle diğer versiyon kontrol sistemlerine alışmış ve halinden memnun olan insanlar yadırgayabiliyorlar, işlerin gereksiz karmaşıklaştırıldığını düşünüyorlar. bence karmaşıklaştırılıyor olsa bile gereksiz karmaşıklaştırılmıyor, yukarıda saydığım ve benim kendimce daha karmaşık çözümler ürettiğim bir sürü problemi çok güzel çözmüş. aslında birşeyi karmaşıklaştırdığı görüşünü de paylaşmıyorum, sadece farklılaştırıyor, ve alıştıktan sonra gündelik kullanımda diğer versiyon kontrol sistemlerinden daha fazla veya daha az yormuyor diye düşünüyorum.

özetle bence git doğru seçim.