Kod gozden gecirme sureci ve GvR amcanin katkilari

Gecen gun Google App Engine ile bir seyler denerken farkettim ki sundugu SDK'de bulunan appcfg.py ile elimizdeki kodu teslim etmeden once yaptigimiz degisikliklere gozatma imkanimiz yok. Kodlarimizi svn gibi bir surum denetim dizgesi kullanmamiz gerekiyormus. oysa app engine'deki surum numaralarini gorunce sonuncu ve simdiki araasindaki degisikliklere bakabileceimi sanmistim.

google'da "google app engine pre commit diff" gibi bir arama yapinca karsima http://code.google.com/p/rietveld/ geldi. parkyeri'nde zamanla ve acilar cekerek kesfettigimiz kod gozden gecirme surecinin cok benzerini google'da da kullaniyorlarmis ve Guido van Rossum(GvR - python'un yaraticisi ve hala yon vericisi, etkin kod gozden gecirici) amcamiz google'a girdikten sonra ilk proje olarak bu sureci iyilestirmek icin kollari sivamis, mondrian diye bir arac yazmis.

bizim mevcut yapimiz asagidaki gibi ve google'daki ile fazlasiyla benzerlik gosteriyor, meraklilari icin parantez icerisine kendi kullandigim araclari yazdim:

1. bir kisigereken kodu yazar (emacs ... | vim ...)


2. yama uretir (svn diff > ticket_no.patch)


3. ilgili gelistirme grubuna gozden gecirme icin eposta atar (mutt -a ticket_no.patch hede@parkyeri.com)


4. gruptan bir kisi kendi deposuna yamayi uygular (patch -p0 < ticket_no.patch)


5. kodu inceler (emacs ... | vim ...)


6. kodu inceleyen kisi epostadaki yama icerisine notlarini yazar ve kodun yazarina gonderir, (mutt)
   (ya da benim genelde yaptigim gibi yazan adam ile dogrudan konusarak sosyal yollarla da cozebilir (finch, konusma))


7. kodu ilk yazan kisi kodu tekrar duzenler ve tekrar yama uretip gonderir (svn diff ... , mutt -a ...)


8. bu surec, kodu gozden geciren kisi "eline saglik teslim edebilirsin"(este) (Enver'den bize miras olarak kaldi) diyene kadar tekrarlar (bazen yamalarimiza changelog eklemedigimiz icin "este" yerine "changelog ekleyip teslim edebilirsin[cete]" cevabi da gelebilir)


9. son olarak da "este" alan kodlarimizi teslim ederiz (svn commit)

Kullandigim araclar basit gozukebilir, ama genel olarak islerini guzel yapan araclar ve cok da fazla dis yardima ihtiyac kalmiyor. Genellikle kodlarimizi ssh ile eristigimiz uzaktaki makinalar uzerinde gelistirdigimiz icin diger gelistiricilerin ev dizinlerinden onlarin neler yaptigini izleyebiliyoruz ve yama alisverisi eposta uzerinden olmak zorunda kalmiyor hatta bir cok durumda yama alisverisi bile olmuyor, girip diger bir gelistiricinin proje dizininde "svn diff | vim -" diyerek kodlari okuyabiliyorum, ancak bunlar gorece kucuk olmamizin getirileri.

Kucuk projelerde artik gozden gecirme surecimiz dahi olmuyor, degisikliklerin takibi ve teslim sonrasi gozden gecirme icin svn teslim epostalari, Trac ve eklentileri yeterli.

Gozden gecirmenin onemini anlatip duran ve bunu python gibi buyuk bir projeyi yonettigi icin yapmak da zorunda olan GvR amcamiz zamaninda ortaya koydugu mondrian'i fazla google bagimli oldugu icin (perforce ve bigtable gibi bagimliliklar yuzunden) acik kaynak haline getirememis, ancak daha sonra Rietveld adiyla acik kaynak olarak da yayinlamis ve diger acik kaynak projelerin kullanimina CodeReview adiyla google app engine uzerinden acmis.

Aracin (rietveld) ornek kullanimi burada.

Tercih ettigimiz araclar

Az önce Serdar ile konuşurken birlikte çalıştığımız şirketlerdeki çalışanların bize göre ne kadar farklı araçlar kullandığından bahsediyorduk. "Abi HTTP başlıklarını gezginden değiştirebileceklerini bile bilmiyorlar" diye söze girmişti Serdar, sonrasında da bizim IE özürlü olduğumuzdan devam ettik. Şirkette pek windows makinalarla uğraşmayı tercih etmediğimiz için ürünlerimizi bazen IE ile test etmekte zorlanıyoruz.

Yazdığımız uygulamalar UNIX türevi sunucularda koştuğu için arkauçlarda genellikle pek sorunumuz olmuyor. Ama web üzerinden erişilen kısımlar için IE ve Safari testleri yapmak zorunda kalıyoruz. Bu tür testeri genellikle şirket içerisinden bağlandığımız Windows ve Maç sunucular üzerinden yapıyoruz, sağolsunlar.

Parkyeri'nde çalışan profilimizden dolayı genellikle özgür olan araçlar kullanmayı tercih ediyoruz. Bu aslında pek de bilinçli bir tercih değil; ama para verip uygulama satın alıp, üzerinde geliştirme yapmaya alışmış insanlardan oluşan bir kadroya sahip değiliz.

Şu anda ilk geldiğimden oldukça farklı ve daha iyi bir konumdayız, biraz kalabalıklaştık, ve kendi adıma birlikte çalışmaktan daha çok zevk alacağım insanlar geliyor Parkyeri'ne. Zamanla değişimimizin kullandığımız araçlara yansıyan bir kısmını aşağıda görebilirsiniz.

Parkyeri'ne ilk geldiğimde benim için çok yeni olan ama hayatımı değiştiren bir çok aracı tanımak zorunda kalmıştım, hayatımı etkileyenlerden aklıma gelenler sırası ile şunlar:

- debian ve gnome: Şirketteki tüm masaüslerinde debian çalışıyordu ve herkes gnome kullanıyordu ve ben o güne kadar hep KDE kullanagelmiştim. İnsanların neden Gnome tercih ettiğini Gürkan Aslan'dan "masaüstü eğitimi" alıncaya kadar pek de anlamamıştım. Gürkan daha sonra Debbie ve Ian'ı, RMS'ın kim olduğunu, GNU'nun ne demek olduğunu başka bir eğitimde anlatmıştı. Güzel günlerdi.

- ssh: Ürünlerin yönetimi ile ilgilendiğim ve müşterilere destek verdiğim günlerde benim için sadece sunuculara açılan kapıydı. Yerelimde nasıl çalışabiliyorsam uzakta da aynen çalışmamı sağlayabiliyordu, ama gene de telnet'ten sonra tüm dünyam aydınlanmış gibiydi. Kimi sunuculara bir kaç makina üzerinden hoplayarak gitmem gerektiğinde de sorun çıkmıyordu, bir süre sonra uzaktaki makinaların portlarını yakınlara taşımayı da öğrendiğimde henüz bu bilginin, katı erişim kısıtlama politikaları olan müşteriler için kod geliştirirken ne kadar işe yarayabileceğine dair fikrim dahi yoktu.

- firefox: zaten kullanageldiğim süper araç, neresini anlatayım ki!

- firebug: 20$ bağış yaptığım firefox eklentisi. IE de debug yapabilmek için koskoca script debugger kurduğum ve her çalıştırmamda IE'yi donduran hımbıl programlar ile uğraştıktan sonra dünyayı yeniden keşfetmemi sağlayan nane.

- livehttpheaders: HTTP başlıklarında gelen giden verilere erişip üzerinde oynama yapabildiğiniz süper eklenti. Özellikle bizim gibi cep telefonu modeline göre farklı wap sayfaları getirecek sistemler gibi bin bir farklı başlık bilgisinin olduğu sistemler ile sık uğraşmanız gerekiyorsa HTTP başlığında telefonu ya da başka bir uygulamayı taklit edebilmenin gücünu bilyorsunuz demektir.

- tamperdata: bir sitenin açılışında hangi dosyaların yüklendiğini görebildiğiniz bir grafik de sunabiliyor. Ürettiği grafiği biraz daha derin şekilde incelerseniz hangi JS dosyalarının firefox tarafından ne kadar sürede ayrıştırıldığını (parse edildiğini) da çıkartabiliyorsunuz. Bizim gibi masaüstü uygulaması tadında web uygulaması (JS kodu) geliştirmeniz gerekiyorsa eklentinin çıktısı olan grafiklerin derinlemesine incelemesi sizi güzel çözümlere götürebilir.

- emacs: Parkyeri'ne geldikten sonra Haldun'un (Parkyeri mezunudur kendisi) ve Erhan'in gazı ile öğrendiğim, genellikle içinde yaşadığım, bu blog girdisini yazdığım şey! Bilgisayarımda sırasıyla XFÇE, firefox ve sonra emacs açılır her ne hikmetse :) psvn gibi uzantıları (vc) ve içerisinde lisp kodlayarak özelleştirilebilir olması vim'den emacs'e geçmemin nedenidir. bir kez açarsınız, içinde yaşarsınız.

- vim: programcı dostu, emacs'e göre çok hızlı yüklenen geliştirme ortamı. (Gerçe Emacs'ı sadece bir kez açıyoruz.)

- etags: vim ve emacs kullanıyorsanız projenizdeki dosyalarda yer alan işlevleri (fonksiyonları) tag'ledikten:

"fınd . -print | etags -"

sonra, kod içerisinde gezinirken vim'de C-], emacs'de M-. tus bileşenleri ile o fonksiyonların tanımlandığı dosya ve satıra erişebilirsiniz. "E, eclipse bunu zaten yapıyor" deyebilirsiniz ama bellekte kapladığı yeri de düşünüyorsunuz değil mi? Bu yöntemde hangi dili kullandığınızın pek önemi yok.

- screen: tüm geliştirme ortamlarınız bizim gibi tamamen uzakta ise ve arkadaşlarınızın tümü uygulama geliştirme sunucularına erişmek için ssh üzerinden uzaktaki vim, emacs gibi araçları kullanıyorlarsa türkiyenin altyapısına olan güvenden haberdarsınızdır. Uzaktaki bir bilgisayarda kod yazarken bağlantı her gittiğinde küfretmek istemiyorsanız screen kullanın. Uzaktaki makinelerde ~/.bashrc içerisine koyduğum aşağıdaki satırlar kişisel olarak çok işime yarıyor doğrusu. Konsol için windows'daki "duraklat" (hibernate) özelliğini çağrıştırıyor.

if [ "x${TERM/-w/}" == "xscreen" ]; then #sometimes it sould have screen-w
echo You are inside a screen.;
else
screen -Rd;
fi

- rcs, cvs: eskiden versiyon takibi için bu meretleri kullanırdık. Parkyeri içerisinde cvs'imiz pek kısa ömürlü oldu, rcs zamanından gelen değişiklik bilgilerini kaybetmeden cvs geçişi yaptıktan kısa bir süre sonra da svn'e geçtik. ama sistem yönetimi için kimi yapılandırma dosyalarının takibinde hala RCS kullandığımız yerler de var.

- svn: Enver'in çabaları ile eski sistemleri bırakıp svn'e ilk geçtiğimizde biraz garip gelmişti, her yeni teslimde tüm projenin revizyon numarasının yükselmesi gibi gariplikler vardı. SVN'in inceliklerini öğrenmek biraz vakit aldı. Ama ne olursa olsun şirkete ait bir projede kendi dalınızı açmak gibi bir lükse sahip olmanın anlamını ancak yaşayan bilir sanırım. svn teslim epostaları ile geliştiriciler kod deposuna yaptıklarını teslim ettiğinde projedeki ilgili herkes değişiklikleri anında görebiliyor.

- dcl: Bilet takip sistemimiz. Zamanında üzerinde değişiklik yaptığımız bir sürümünü kullanıyoruz. Müşterilerin ilettiği her sorun için bilet (iş havalesi) açıyoruz... Bir çok firmada bir şekilde vücut bulan bildiğiniz iş takip sistemi.

- webcalendar: Şirket içerisinde toplantı yönetimini ve kimin ne zaman hangi ofisimizde olacağını bu uygulama ile takip ediyoruz.

- trac: Kimi projelerin işlerini takip ederken dcl yerine trac kullanamyi tercih ediyoruz. svn depolarımızla birlikte çalışabilmesi "proje maddeleri" (biletler) ve "geliştirilen kod" arasındaki ilişkiyi çok net kurabilmemizi sağlıyor.

- jmeter: Uygulamanızı çok çeşitli şekillerde test edebilmenizi sağlayan pek eşi olmayan nane. Birim testlerimizi web üzerinden tetikleyen ve servislerinize ait istatistiki bilgi üretebilmenizi sağlayan bir araç. Yaptığı isteklerin sonuçlarını sizin belirlediğiniz kriterlere göre denetleyebilen, yeri gelince çıktıdaki xml'i ayrıştırabilen, yeri gelince aldığı cevabın doğruluğunu veritabanından deneteyebilen ölçen süper araç. Türkiye'nin hatırı sayılır kesiminin kullandığı uygulamalar gelişiriyorsanız yük testleri yaparken bir çok makina üzerinden paralel (dağıtık) çalışabilmesi de çok işe yarıyor.

- apaçhebench: HTTP üzerinden çalışan servisleriniz için oldukça ağır yük testlerini yapabileceğiniz araç. jmeter gibi çıktı üzerinde doğrulama yapamasa da basit bir kaç betik ile birlikte kullandığınızda sisteminizde aşırı yük yaratmak ve etkilerini ölçmek açısıdan oldukça faydalı.

- postgresql: Yalan atmama gerek yok sanırım, oracle gördüğümüz yere postgresql koymak için çaba harcıyoruz. Oracle kullanmaya mecbur kalmadıkça kullanmıyoruz. Postgresql zaten yük dengeleme, yedekli çalışabilme gibi kritik uygulamalarda şart olan özelliklere sahip. Oracle'da protokollerin, işletim sisteminin ya da sitemin kendisinden kaynaklanan sınırlara dayandığınızda işin içinden çıkmak için bir oracle uzmanı bulmadan edemiyorsunuz.

- mysql: mysql üzerinde çok zamandır koşan servislerimizin milyonlarca kayda rağmen tökezlemediğini bilmek iç ferahlatıyor.

- memcached: uyulamanız yükleri paylaştırmak için n tane makina üzerinde koşuyorsa size gelen her isteğin farklı bir fiziksel makinaya iletilmesi session kullanımınızı etkileyebilir veya ağır yük altında veritabanı işlemlerinizi cache'lemeniz gerekebilir, bir sürü makinada paralel çalışabilen bu küçük programcık hayat kurtarabiliyor.

Kullandığımız araçlardan ilk çırpıda aklıma gelenler şimdilik bu kadar. Bir çok kişi için bunlar pek bir şey ifade etmese de belki bir gün birilerinin işine yarayabilir.

Blögged with Flock

Parkyeri'nde yasadiklarimdan ogrendiklerim

1 Ekim 2004'ten beri Parkyeri'nde calisiyorum, 3 senelik Parkyeri
tarihimde gorduklerim gecirdiklerimden sunlari ogrendim diyebilrim.



gelistirme, test ve gercek ortam'in ne oldugunu,

bir sirketin aldigi yazilimi isletemeyip nasil baska bir sirkete
islettigini ogrendim, urunu ben islettim ve uzerindeki yeteneklerde
gore gelistirme talep etmeknin nasil bir sey oldugunu, ne kadar
zamanda cevap alabildigimizi,

programcinin zamaninin degerli oldugunu, isleri destek tarfina nasil
aktarmak gerektigini,

rcs ile gelistirme yapmanin olumsuz yanlarini, baskasindan nasil dosya
calacagimi, baskasinin adina nasil dosya teslim edecegimi,

rcs'in sistem yonetiminde ne kadar faydali bir arac oldugunu,

sistemlerin uptime'larinin gercekten ne demek oldugunu,

veritabanindaki 4 milyon kaydin nasil bas agritabildigini,

dosya sisteminin 2gb dosya sinirinin log dosyalarini nasil
etkileyebildigini,

bir sirketin projelerine ait kod tabanlarinin rcs'den cvs'e ve svn'e
gecmesinin ne kadar surebilecegini,

uygun indexler yaratilmamis veritabaninin tum sistemi ne kadar
aksatabildigini,

sirketler icerisinde isleri takip icin kullanilabilen sistemlerin
hantalligini ve ne kadar hareketli olabildiklerini,

trac'in sirket ici kullanimda da ne kdar guzel olabildigini,

kod yazma, gozden gecirme ve test adimlarinin projelerde ne kadar ise
yaradigini, birisinin yazdigi kodu illa ki bir digerinin okumasi
gerektigini,

onsite calisma'nin ne demek oldugunu buyuk bir musteride 1 ay
calistiktan sonra ancak,

onsite calismanin bir projedeki isleri ne kadar hizlandirabildigini,

musterinin belirledigi sartlarda calismanin ne demek oldugunu,

proje plani yapmanin, gannt chart cikarmanin, paralel isleri
planlamanin ne oldugunu,

kodlari musteriye teslim edilen ve kodun teslim edilmeyip servisin
sunuldugu projelerin hafifligini ve agilirini,

servisini kendin isletmenin maliyetini,

bir sirketin kendi servislerini islettigi kac sunucusu olabilecegini,

yedeklenmeyen loglarin yeri geldiginde ne kadar olumcul
olabildiklerini,

kritik uygulamalarin loglarinin anlik takibinin nasil yapidigini,

operasyonun ne demek oldugunu,

bir operasyon icin kac kisi ayrilabildigini,

arka arkaya kac gece operasyon yapilabildigini,

surum deposu yedeginin ne kadar faydali olabildigini,

ve ydeeklenmeyen gelistirme ortamlarinin ne kadar calismaya mal
oldugunu,

gelistirme araci olarak vim ve emacs'in yeterli oldugunu,

uzak makinalarda vim ya da emacs olmamasinin ne demek oldugunu,

sadece vi (vim degil) operasyon yapmanin yerel atarlari bozuk sistemde
nelere yolacabilecegini,

emacs'in elisp'le ne kadar guclu olabildigini,

eclips'in ne kadar bellek tukettigini,

vim'in bir editor olarak hizli yuklenmesinin degerini,

emacs'in neden kapatmamak gerektigini,

emacs ve mount'un bir bilgisayar icin yeterli olabildigini,

mutt ile epostalara bakmanin rahatligini,

ssh ile tunel kazmanin gucunu,

ssh'in telnet'e gore ne kadar tehlikeli olabilecegini,

bazen kac makina uzerinden ilerlemek gerekebildigini,

bash betiklerinin ne kadar cok isi tek basina halledebildigini,

python ile ne kadar ne kadar hizli kod yazilabildigini,

bir suru framework'u bilmek yerine, bir framework'u cok iyi bilmenin
neler kazandirabildigini,

perl ile ne kadar cok regexin hatiri sayilir bir basarim ile
islenebildigini,

php ile kodlarin saklanamamasinin yol actigi kafa karisikligini,

ajax'a fazla bagimli kalip uygulamanin desktop application'a donustugu
anda cikabilecek sorunlari,

java classpath'inin ne demek oldugunu,

goc (migration) sirasinda unutulup kaldirilmayan indexlerin tum
sistemi nasil etkileyebilecegini,

bir kac milyon kayitlik bir migration'in ne kadar zamanda
sonlanabilecegini,

ciktigimiz surumleri dogru duzgun takip edebilecegimiz bir yapiyi
kurmanin zorlugunu,

dunyanin buyuk sirketlerinin nasil calistiklarini,

yurtdisinda yapilan projelere turkiyeden nasil destek verilebildigini,

bir musteri icin kac proje yapilabildigini,

25 kisilik bir sirketin kac aktif projesi olabildigini,

projeyi fazla takip eden ve hic ilgi gostermeyen musterilerin
acabilecegi sorunlari,

bir sirkette kac farkli dil kullanilabilecegini,

paket halindeki urunlerin kac kez satilabilecegini,

yapilandirma dosyasina koyulmayan verilerin gercek ortamda nelere mal
olabilecegini,

icerik sistemi yerine kati kodlanan verilerin acil durumlarda ne kadar
soruna yol acabilecegini,

yorumlanan ve derlenmeyen dillerin ne kadar hayat kurtarablecegini,

deploy'un ne demek oldugunu,

kullandigim dilin kutuphanelerinin olgunlugunun ne kadar onem
tasidigini,

pear'a cok da guvenmemek gerektigini,

php5 ile php4 arasindaki guzel farklari,

php4'ten php5'e gecmenin ne demek oldugunu,

kaynak koddan program derleyebilenin ne kaar buyuk yetenek oldugunu,

apache gibi programlarin sun makinalarda ne kadar derlenemez isletim
sistemleri oldugunu,

rfc'lerde hic dikkat etmedigin bir kac parametrenin agir yuk altinda
ne kadar oneli olduklarinin anlasilabilecegini,

proxy'nin ne oldugunu, reverse proxy'nin ne oldugunu,

apache kurulusunun yazilimlarini yelpazesinin ne kadar genis oldugunu,

yuk testi yapmanin ne demek oldugunu,

yuk testi yaparken kullanilan aletlerin ne kadar yetersiz
olabildigini,

basit aracarin buyuk kurumsal cozumlerden ne kadar daha etkin oldugunu,

kod yazarken birim test yazmanin onemini,

birim testlerde hata veren surumun durumunu,

birim testleri yasatmanin guclugunu,

test frameworklerinin bazin en kadar yetersiz kaldigini,

nigthly built'lerin onemini,

kullanici testlerinin onemini,

vip kullanicilarinin ne kadar etkin insanlar oldukarini,

araba verilen bir yarismanin sonucunun ne kadar onemli oldugunu,

anlik baslatilan ve sonlanan yarismalarin nasil baslatilip
bitirildigini,

bir araba azanmak icin kac kisinin bir yarismaya katilabilecegini,

bir gazete bulmacasini kac kisinin cozebildigini,

jmeter'in testlerde ne kadar ise yaradigini, ne faydali sonuclar
uretebildigini,

python ve perl kutuphanelerinin ne kadar zengin oldugunu,

programlarin arka arkaya gelen surumleri arasindaki hayati
degisiklileri,

woody'den sarge'a ve sarge'dan etch'e gecmenin ne demek oldugunu,

debian depolarindan bir paketin kalkmasinin nelere yol acabildigini,

bir projende veritabani olarak sadece belirli bir veritabanini (mysql,
oracle, postgresql) kullanmanin yaratabilecegi sorunlari,

tasarim yapmanin ne demek oldugunu,

tasarimin kac kisi tarafindan yapilabildigini,

bir projenin en cok kac api'ye baglanabilecegini,

bin tane api'nin ne kadar zamanda okunabilecegini,

bir projede kac partinin birbirinden basgimsiz ama birbiri ile ilgili
dokuman uretebilecegini,

bir projede kac sayfa dokuman uretilebilcegini,

entegrasyon projesi'nin ne demek oldugunu,

elde olan basit wsdl'larin ne kadar bas agritabildiklerini ve tcpdump
ciktisinin ne kadar degerli olabildigini,

bea'nn ne demek oldugunu,

kullandigimiz dilin kutuphanelerinin acik kaynak olmasinin onemini,

dogru takim ile sabahlamalarin ne adar eglenceli oldugunu,

kac gun boyunca sikilmadan sirkette kalinabildigini,

rfc'leri okuyabilmenin ne kadar degerli bir yetenek oldugunu,

xml'in ne oldugunu,

xsl'in nerelerde kullanilabildigini,

xslt'nin ne oldugunu,

dunyanin html'den ibaret olmadigini; wml, xhtml gibi seylerin de
oldugunu,

javascript biliyorum demenin ne demek oldugunu,

maymun istahli insanlarla calismanin zevkini,

amerikalilara degil turklere gore encoding'in ne demek oldugunu,

bir projenin ongorulenden ne kadar daha uzun surebilecegini,

projedeki cok acil islerin musteri yuzunden ne kadar uzun surede
cozulebilecegini,

acil diye bir seyin olmadigini,

her seyin acil oldugunu,

urun yonetmenin ne demek oldugunu,

musteri sorumlulgunun anlamini,

gunluk yazarken bile emacs kullanamnin ne kadar rahat oldugunu,

isyerinde windows degil linux kullanilabildigini,

isyerinde her gun istedigin masaya oturabilmenin rahatligini,

calis(ma)mak istedigin insanlari secme ozgurlugunun ne demek oldugunu,

yazlari cesme ofisinde calismanin, denize girip gelmenin ne demek
oldugunu,

creaworld icinde calismanin neye benzedigini,

tasarim desenlerinin (desing pattern) ne oldugunu, nasil hayat
kurtardiklarini,

bir sirkette kutuphane kurmanin nasil olabilecegini,

sirkette kimsenin okumadigi kitaplarin kattigi degeri,

kraldan cok kralc olan insanlarin ne kadar zararli olabildikleri,

prosedurlerin islerin onunu nasil tikayabildikleri,

proje yonetirken calsanlarin nasil da cil yavrusu gibi dagildiklarini,

arttirmandirmanin ne oldugunu,

bir calisana mevki ver(me)menin onemini,

ozgur yazilimlarin icinde yasayip hicbirisine katkida bulunmamanin
agirligini,

arkadaslarinla tekne takimi cikarmak icin birlikte hareket edebilmenin
hafifligini,

bir takimin sorumlulugunun ne demek oldugunu,

yorgun oldugun zaman bir arkadasin yardima kosmasinin degerini,

icinde yer aldigin sirketin geleceginde gorunur bir etki sahibi
olmanin mutlulugunu,

birlikte olmaktan mutlu oldugun insanlarlar mutlu mesut yasamanin
hayati ne kadar cekilir kildigini,

ideallerinden vazgecmeyen insanlarin bir arada neler yapabilecegini,

dusunen cok kafa olmasinin ne kadar gurultuye yok acabilecegini,

yeri geldiginde arkadaslarinda evden calismanin ne kadar guzelbir sey
oldugunu,

xp tarzinda calismanin nasil bir sey oldugunu, musterinin kartlari
doldururken sana guvenini hissetmenin hazzini,

kimin proje sorumlusu olmak istediginin ortaya sorulmasinin ve bunun
kultur olmasinin nasil bir rahatlik oldugunu,

projelerin bitmemesinin bazen neden daha iyi oldugunu,

cevrendeki insanlarin zamanla degismesinin onemini,

cevrenden her konuda senden daha iyi insanlarin bulunmasinin nasil bir
nimet oldugunu,

cevrendeki insanlarinin meraklarinin ne kadar bulasici olabildigini,


iste bulari parkyerinde ogrendim.

trsec konferansi notlarim

gittigim, trsec konferansinda ldigim notlar asagida.

seminer daha cok satir odakli idi ama gene de dunyada guvenlik sektoru ne alemde ve insanlar nasil calisiyorlar ufuk aciyor. oturumlar ve aklimda kalanlari oylece dusenlemeden yazdim.



aviram jenik - Breaking virtual keyboards

virtual keyboard uygulamasinin nasil bi koruma sagladigini anlatti,
bir bakanin uygulamasinin incelemesini ve daha guvenilir olmasi icin
nelerin eksik oldugunu anlatti. garanti banlasinin uygulamasini ornek
olarak gosterdi.

sirketlerinde "fish or not" adli bir oyun oynuyorlarmis, birbirlerine
banka gibi kuruluslardan gelen epsotalari gonderereek bunun bir
fishing mi yoksa gercekten kurumun epostasi mi oldugunu anlamaya
calisiyorlarmis.

guvenlik konusunda yapilan genel hatalari soyle siraladi: relying
client side, obfuscation, complexity





2. Christoph Fischer - Online crime and phishing

gelecege bakis

pachlenmemis windowslar buyuk tehdit ve hala cok sayida varlar. bunlar
bir cok konuda acik kapi olarak hala varlar.

organized crime- cinli bir grup buyuk bir aga sahip (yuzbinlerce
bilgisayar) ve bu bilgidayarlardan elde etitkleri bantgenisligini ve
islemci gucunu satiyorlar.

asus ve windrive siteleri hacklenmis, dogrudan kullanicilarin surucu
indirdikleri siteler. insanlarin buradan aldiklari exe leri
calistiracaklari asikar

dunyada cok yaygin kullanimi olan sitelerde degisiklik yaparak cok
kucuk js kodu eklemisler, XSS icin birebir.

zert, avds, beSTORM, WebHoneyNet --> bunlar hizli yama cikmayi(0-day),
kotulerin calisma yontemlerini anlamaya ve zayiflik testleri yapmayi
hedefleyen girisimler.






Ziya Gokalp, servus - Access Control & Authentication Systems

amca daha cok kurumunun hizmetlerini tanitmaya yonelik bir sunum ile
gelmisti, sso ve otp icin slaytlar ile bir kac uygulama anlatti, biraz
monton idi, katilimcilardan bunalri bilmeyen oldugunu fazla
sanmiyorum. sunumun tumu su noktalara deginiyordu:

erisim yetkilendirme - sso
kimlik yonetimi (im) - tek kullanimlik sifre(OTP), pki, sso, im

bunlarin yonetimini nasil merkezilestirip cok makinadaki hesaplari
yonetmenin maiyetini azaltabiliriz.






netsmart - endpoint security - ozgur midik

sadece pc ve sunuculara yuklenmek yanlis olur, cep telefonlari,
laptoplar, smartdiskler d birere uc nokta.

icerideki pc'leri ve sunuculari cok guzel koruyoruz ama insnlarin
evinden getirip taktiklari tek bir flash disk butun agimizi
cokertiyor.

bazen koruma sadece agin onunde duran firewall'lar ile oluyor, ama
iceriye giren bir laptop her seyi dagitabiliyor. iceride olup
bitenleri denetlemiyorlar. usb diskler, laptolar, cdler buyuk
tehdit. bunlari yasaklayan sirketler biraz daha guvenlik
saglayabiliyorlar. ama ornegin otp token'i icin acik birakilan bir usb
portu her seyi mahvedebilir.

csi/fbi 2006 computer crime and security survey - computer security
institute'den istatistikler goruntuledi ve uzerinde bir cok yorum
yapti


birisi cikip insnlari engellemeye calismak yerine bilinclendirmeye
yatirim yapmanin daha mantikli olup olmadigini, herkesin potansyel
guvenlik uzmani olabilecegini sordu, millet bir tarafiyla guldu. bizim
sirketi dusundum ben de guldum. bizde calsiiyor gibi geldi, tabii daha
30 kisiyiz, ve getirdigi sorunlari tartismak da can sikar.






aviram jenik - Estonia: Information Warfare and Lessons Learned

bu oturumda daha cok siber savaslari anlatti.

tum estonya aginin kilitlenmesinin sorumlularinin hala tam olarak
bilinemiyormus. sirketleri (beyond security) estonya agi cokunce
yardim icin cert-ee ye yardim icin bir "rescue team" gondermis.(bcp38
kullanmislar ve cok yardimi olmus.)

israil-arap siber savaslarini anlatti, o sralarda odagimiz dagilmisti.






beyond security'den baglanan amca

skype ile beyond security'den (almanyadaydi sanirim sanirim) bir amca
baglandi ve bir sunum yapti, onceleri kendilerinin gectikleri yollari
ve basarilarini anlatirken tam bir sirket sunumu yapiyordu ve
fazlasiyla baydi.

biraz daha ilerleyince hackererin kullandiklari araclari ve nasil
calistiklarini, ve hatta ucret tarifeleri ve araclarini ekran
goruntulerini gostererek anlamaya baslayinca nutkum tutuldu. tek
kisinin altindan kalkalmayacagi buyuk oranize isler ve urettikleri
inanilmaz seyler, yaptiklari projeler'in cogunu sanirim siret olarak
gelistirmemiz yillari gecerdi. donen paralarin, islemci gucunun, spam
kapasitesinin, bantgenisligi miktarinin haddi hesabi yok.

bu kotu amcalarin kullandiklari su uygulamalarin neler
yapabildiklerini ekran goruntuleri ile anlatti: goldun ,haxdoor,
metafisher(cz), webattacker.

undergroun olarak adlandirabilecegimiz gruplarin kredi karti
bilgilerini, farkli profillerde eposta adreslerini, islemci gucunu
satarkenki fiyat listeleri, bu isleri yapan grupar sanirim son derece
belirli. konusmasi sirasinda kredi karti bilgileirni 5$ a alip 7$a
piyasada satanlardan falan bahsetti amca.