Linux Admin

Showing posts with label acik kaynak. Show all posts
Showing posts with label acik kaynak. Show all posts

Wednesday, September 17, 2008

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.

Wednesday, October 31, 2007

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